Re: [squid3-ipv6] NEW INDEXING SCHEMA for Cache-peer
Rafael Martinez Torres wrote: Sorry my bad cut-n-paste. I meant to send: I realised. k. no prob, just wondering. BTW - the client table remains IP indexing... I think that is not a problem. - Where should I upload the scripting tests ? under scripts/? Everything in-there is perl code... And mine is sh . Any problem with that ? I'm still trying to figure out the less-used directories myself. I think test-suite for post-compile tests. It looks more like scripts is runtime extras for various installs. Maybe someone else will say. Amos
Re: [squid3-ipv6] NEW INDEXING SCHEMA for Cache-peer
> Sorry my bad cut-n-paste. I meant to send:
>
I realised.
> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.1 = INTEGER: 1
> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.2 = STRING: "www.google.es"
> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.3 = INTEGER: 1
> SNMPv2-SMI::enterprises.3495.1.5.1.1.1.4 = STRING: "64.233.183.104"
> ...
> SNMPv2-SMI::enterprises.3495.1.5.1.1.2.1 = INTEGER: 2
> SNMPv2-SMI::enterprises.3495.1.5.1.1.2.2 = STRING: "www.google.es"
> SNMPv2-SMI::enterprises.3495.1.5.1.1.2.3 = INTEGER: 1
> SNMPv2-SMI::enterprises.3495.1.5.1.1.2.4 = STRING: "64.233.183.104"
>
OK, OIDs are ordered, but peer table is indexing by a "double index",
{cache_peer_index-atributefield}. It is not the idea specified by actual
MIB.txt. If you prefer this, start by change the MIB, and then reprogram the
agent acordingly .
However this is not the "standard" way for indexing this sort of instances.
just take a look for the given rfc2465, that of several IPs by ethernet
card . I readapted the idea from there...
And every graphing program should be ready to interpret the correct indexing.
Still if you want to split the output for the two cache peers ( the original
bad copy-n-pastte,you can try the atacched script ) It works but notably
slower...
(Change your ip addresses )
> >
> >> 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"
> >
BTW
- the client table remains IP indexing... I think that is not a problem.
- Where should I upload the scripting tests ? under scripts/? Everything
in-there is perl code... And mine is sh . Any problem with that ?
test.amos.snmp
Description: application/shellscript
Re: [squid3-ipv6] NEW INDEXING SCHEMA for Cache-peer
Rafael Martinez Torres wrote: 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 )! Sorry my bad cut-n-paste. I meant to send: SNMPv2-SMI::enterprises.3495.1.5.1.1.1.1 = INTEGER: 1 SNMPv2-SMI::enterprises.3495.1.5.1.1.1.2 = STRING: "www.google.es" SNMPv2-SMI::enterprises.3495.1.5.1.1.1.3 = INTEGER: 1 SNMPv2-SMI::enterprises.3495.1.5.1.1.1.4 = STRING: "64.233.183.104" ... SNMPv2-SMI::enterprises.3495.1.5.1.1.2.1 = INTEGER: 2 SNMPv2-SMI::enterprises.3495.1.5.1.1.2.2 = STRING: "www.google.es" SNMPv2-SMI::enterprises.3495.1.5.1.1.2.3 = INTEGER: 1 SNMPv2-SMI::enterprises.3495.1.5.1.1.2.4 = STRING: "64.233.183.104" Not sure if your answer would be I understand why it won't work the way I sent first time. Thanks. (but with the last two .detail.peer entries int reversed order .peer.detail) Otherwise it looks good. Amos Amos
Re: [squid3-ipv6] NEW INDEXING SCHEMA for Cache-peer
> > 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
Re: [squid3-ipv6] NEW INDEXING SCHEMA for Cache-peer
> > By the way, it also works for "several peers on a same IP". See > result2.txt > > >> I am fine with dropping the IP based index in Squid-3 entirely if it >> simplifies things. > OK. >> The only reason why it's in Squid-2 is for legacy >> reasons to not break existing SNMP data collectors using the data. >> >> > However, in Squid-3, we have to, since new OID's like addr_type are > mandatory. > >> Regards >> Henrik > > Regards Rafa > Is there any reason why the PeerIndex is below the field type? 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" 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" ... (but with the last two .detail.peer entries int reversed order .peer.detail) Otherwise it looks good. Amos
Re: [squid3-ipv6] NEW INDEXING SCHEMA for Cache-peer
By the way, it also works for "several peers on a same IP". See result2.txt > I am fine with dropping the IP based index in Squid-3 entirely if it > simplifies things. OK. > The only reason why it's in Squid-2 is for legacy > reasons to not break existing SNMP data collectors using the data. > > However, in Squid-3, we have to, since new OID's like addr_type are mandatory. > Regards > Henrik Regards Rafa 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" SNMPv2-SMI::enterprises.3495.1.5.1.1.5.1 = INTEGER: 80 SNMPv2-SMI::enterprises.3495.1.5.1.1.5.2 = INTEGER: 88 SNMPv2-SMI::enterprises.3495.1.5.1.1.6.1 = INTEGER: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.6.2 = INTEGER: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.7.1 = INTEGER: 2 SNMPv2-SMI::enterprises.3495.1.5.1.1.7.2 = INTEGER: 2 SNMPv2-SMI::enterprises.3495.1.5.1.1.8.1 = INTEGER: 1 SNMPv2-SMI::enterprises.3495.1.5.1.1.8.2 = INTEGER: 1 SNMPv2-SMI::enterprises.3495.1.5.1.1.9.1 = Counter32: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.9.2 = Counter32: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.10.1 = Counter32: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.10.2 = Counter32: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.11.1 = Counter32: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.11.2 = Counter32: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.12.1 = INTEGER: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.12.2 = INTEGER: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.13.1 = Counter32: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.13.2 = Counter32: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.14.1 = Counter32: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.14.2 = Counter32: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.15.1 = Counter32: 0 SNMPv2-SMI::enterprises.3495.1.5.1.1.15.2 = Counter32: 0 End of MIB
Re: [squid3-ipv6] NEW INDEXING SCHEMA for Cache-peer
On sön, 2007-12-02 at 14:48 +0100, Rafael Martinez (Squid development) wrote: > Please, asking for your advice before commiting a non trivial change... > > is this the desired effect ? (Leaving IP indexing on SNMP agent...) I am fine with dropping the IP based index in Squid-3 entirely if it simplifies things. The only reason why it's in Squid-2 is for legacy reasons to not break existing SNMP data collectors using the data. Regards Henrik signature.asc Description: This is a digitally signed message part
Re: [squid3-ipv6] NEW INDEXING SCHEMA for Cache-peer
Please, asking for your advice before commiting a non trivial change...
is this the desired effect ? (Leaving IP indexing on SNMP agent...)
file heinrik.txt shows how mib.txt describes the situation. (not
allowing to change peer's index unless you restart snmp-agent ).
file result.txt shows a full operating run.
If OK, I commit .
PS; Heinrik, just a reminder: on squid3-ipv6 branch we deal with a new
OID (peer_addr_type) to distinguish IPv4 (1) frin IPv6 (2) peers.
--
-- cacheMesh group { squid 5 }
--
cachePeerTable OBJECT-TYPE
SYNTAX SEQUENCE OF CachePeerEntry
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This table contains an enumeration of
the peer caches, complete with info "
::= { cacheMesh 1 }
cachePeerEntry OBJECT-TYPE
SYNTAX CachePeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" An entry in cachePeerTable "
INDEX { cachePeerIndex }
::= { cachePeerTable 1 }
CachePeerEntry ::= SEQUENCE {
cachePeerIndex CachePeerIndex,
cachePeerName DisplayString,
cachePeerAddressType InetAddressType,
cachePeerAddress InetAddress,
cachePeerPortHttp Integer32 (1..65535),
cachePeerPortIcp Integer32 (1..65535),
cachePeerType Integer32,
cachePeerState Integer32,
cachePeerPingsSent Counter32,
cachePeerPingsAcked Counter32,
cachePeerFetches Counter32,
cachePeerRtt Integer32,
cachePeerIgnored Counter32,
cachePeerKeepAlSent Counter32,
cachePeerKeepAlRecv Counter32
}
CachePeerIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A unique value, greater than zero for each
cache peer instance in the managed
system. It is recommended that values are assigned
contiguously starting from 1. The value for each
cache peer index must remain constant
at least from one re-initialization of the entity's
network management system to the next
re-initialization."
SYNTAX Integer32 (1..2147483647)
END
cachePeerIndex OBJECT-TYPE
SYNTAX CachePeerIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A unique non-zero value identifying
the particular cache Peer."
::= { cachePeerEntry 1 }
cachePeerName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" The FQDN name or internal alias for the
peer cache "
::= { cachePeerEntry 2 }
cachePeerAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The type of Internet address by which the peer
cache is reachable."
::= { cachePeerEntry 3 }
cachePeerAddress OBJECT-TYPE
SYNTAX InetAddress (SIZE (1..64))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Internet address for the peer cache. The type of this
address is determined by the value of the peerAddressType
object. Note that implementations must limit themselves
to a single entry in this table per reachable peer.
The peerAddress may not be empty due to the SIZE
restriction.
If a row is created administratively by an SNMP
operation and the address type value is dns(16), then
the agent stores the DNS name internally. A DNS name
lookup must be performed on the internally stored DNS
name whenever it is being used to contact the peer.
If a row is created by the managed entity itself and
the address type value is dns(16), then the agent
stores the IP address internally. A DNS reverse lookup
must be performed on the internally stored IP address
whenever the value is retrieved via SNMP."
::= { cachePeerEntry 4 }
cachePeerPortHttp OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" The port the peer listens for HTTP requests "
::= { cachePeerEntry 5 }
cachePeerPortIcp OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" The port the peer listens for ICP requests
should be 0 if not configured to send ICP requests "
::= { cachePeerEntry 6 }
cachePeerType OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" Peer Type "
::= { cachePeerEntry 7 }
cachePeerState OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" The operational state of this peer "
::= { cachePeerEntry 8 }
cachePeerPingsSent OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" Number of pin
