> 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 ?
