> PROPOSED NEW TABLE (SQUID-3)
> ==================================================================
>
> The new one would look like:
>
>
> cachePeerAddress cachePeerName cachePortHttp cachePeerPortIcp
> 10.0.0.99 blue 80 21
> 2001:32ef:a221:fb32::1 yellow 82 24
> 10.0.0.51 pink 86 19
>
>
By the way, my mistake, acording to _actual_ SQUID-MIB (on squid-ipv6
branch) cachePeerTable is indexed not only by the IP, but also from the
IP type (1 for IPv4, 2 for IPv6).
cachePeerType cachePeerAddress cachePortHttp cachePortName
1 10.0.0.99 80 blue
2 2001:32ef:a221:fb32::1 82 yellow
1 10.0.0.51 86 pink
Still this does not solve the question introduced by Nostrom
> Note: The cache_peer SNMP index is broken. We can't use IP as the
index
> key as we may have multiple peers on the same IP.
OK. For the time beeing, let's suppose one only peer on the same IP.
Then, when implemented on a solid basis, let's modify the squid.txt
specification to add Nostrom's requirement.
>I'd suggest using an array based indexing scheme instead similar to
>how network interfaces is indexed in ifTable, with the IP being one
>attribute per peer. For configuration stability we might want to add an
>snmpindex parameter to cache_peer so a peer doesn't change index
>position only because another peer is added/removed.
Then we have next choices to fullfill Nostrom's requirement:
- indexing by name:snmpindex (like eth0:0, eth0:1, eth0:2 in ifTable)
- support triple index ( InetAddressType, InetAddress, InstanceNumber)
Any comment ?
Received on Mon Nov 12 2007 - 11:31:21 MST
This archive was generated by hypermail pre-2.1.9 : Sat Dec 01 2007 - 12:00:05 MST