[squid-users] squid-users Digest, Vol 66, Issue 17

[Alex Rousskov]

On 2/15/20 6:42 AM, Scott wrote:
>> From: Alex Rousskov
>>     >a      Client source IP address
>>     >la     Local IP address the client connected to
>>     la      Local listening IP address the client connection was...
>>     <a      Server IP address of the last server or peer connection
>>     <la     Local IP address of the last server or peer connection
>>     icap::<A        ICAP server IP address. Similar to <A.
>>
>>
>> If we add support for automated IP version extraction, it should be
>> supported as a single new parameter for all existing %codes that log IP
>> addresses rather than new %codes (one %code for each of the existing
>> %codes that log IP addresses). For example:
>>
>>     %>a{version}

> bear in mind that normally Squid handles but two connections (c->squid, 
> squid->peer/origin), despite the fact that there are normally four addresses 
> (client, squid-inside, squid-outside, peer/origin).  If it were agreed to 
> support such a logging function, why would one bother having >a{version} and 
> >la{version} when both MUST be the same?  Same goes for <a and <la.

Sorry, I do not understand the relevance of your rhetorical(?) question
because my suggestion does not require anybody to log duplicate
information: If an admin wants the IP version of the client-to-Squid
connection, they can use either >a{version} or >la{version}, whichever
works best for them.

My point was that Squid can already log more than four IP addresses
(corresponding to more than two connections), and that number can only
go up. If additional version logging support is indeed warranted, then
%address_x{ip_version} is a better interface than %address_x_ip_version
or %connection_y_ip_version because the former needs to be documented
and implemented once, while the latter needs to be documented and
implemented once for every [two] address-logging options.

In other words, the "each connection has two addresses" observation
reduces the current pain of adding new %codes by 50%, but my suggestion
reduces that pain by 83% (and approaching 100% long-term).


> As to the suggestion that one differentiate IP versions by the signifier '[', 
> from my experience "%>a" in logformat does NOT provide surrounding square 
> brackets.

Yes, according to Amos, the admin should be using ':' instead. The
presence of a '.' can be used as well AFAICT. I am sorry for throwing a
bracketing red herring into the debate!


> The argument I would make (and I do appreciate you hearing it) is that 
> programmatically (think grep/awk or pcre filtering) it's much easier to 
> determine how much traffic (client/server) is either v4 or v6 is by using a 
> fixed field rather than positive/negative lookaheads in the address codes 
> (given the lack of []).

For grep/pcre, the complexity of using ':' instead of '6' (or '[.]'
instead of '4') seems about the same to me as far as "ease" of filtering
is concerned. You could argue that records with a fixed version field
can be filtered _faster_, but not "much easier" AFAICT.

Not sure about awk.


Please note that I am _not_ arguing against adding IP version logging
yet, just making sure that we use the right logging interface (and that
the arguments used in the debate are valid). I am not convinced either
way yet.

Convincing others that an already logged information should also be
available for logging in a different format would be difficult but
probably not impossible. After all, Squid does support %code .min_width
formatting option that may delete some of the field information and even
%code options that extract partial information (%>h{field} being one of
the best examples); perhaps "log just the IP version" could be seen as a
similar option.


HTH,

Alex.