Re: OID IPv6 values

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

Giving it a whole minutes thought, a triple index sounds best. Although
how/what the third field should be generated is tricky.

Below is a rough brain-dump from me on the topic.

My thought is type-address-(name?).

But really the only fixed values are type:ip.

I know its important to keep it consistent across a run of squid, but;
How important is it that the index remains the same across restarts?
config reloads? Is it likely to impact third-party graphing and logging
done via SNMP?

If the answer to those is generally in the negative, name would be a good
choice. It may vary, but not between reloads, and not short-term.

Arbitrary integer. Maybe the ideal, but some consistency may be needed,
that pulls things back in a circle of how to generate it.

If you want to make way for those future additions, Henrik any idea if
type:ip:port would be unique?

On a Related side-issue:
  Ports may need to be made a variant index column also. I have been
looking at the new attempt at a secure Web3.0 stateless-P2P distribution
for HTTP. That would require a small re-working of the port structure
for peers. Peers tell each other what services are accessible and
through what port, then decide what they need/can use from others.
Which would make the number and type of peer ports unknown to us
developers (no explicitly enumerated cachePeerHTTpPort, cachePeerICPPort,
etc).

Given that we already have optional ICP port, and variant HTTP/HTCP/data
port. Is it worth structuring the table with only a single port column to
cope with that now?

Amos
Received on Mon Nov 12 2007 - 14:36:46 MST