Re: squid-users Digest, Vol 66, Issue 17

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: squid-users Digest, Vol 66, Issue 17

Scott
> Date: Fri, 14 Feb 2020 11:03:50 -0500
> From: Alex Rousskov <[hidden email]>
> To: [hidden email]
> Subject: Re: [squid-users] [Feature request] add IP version to logformat
>  format codes
>
> On 2/14/20 10:36 AM, Scott wrote:
>
> > I know it's derivable by other means, but it would be nice to have a
> > logformat format code that provided the client and server IP version numbers.
>
> > eg: >v for Client IP version (4 or 6) and <v for Server
>
>
> Other than client and server, Squid can log a few other IP addresses,
> including:
>
>     >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}
>
> FWIW, personally, I am not sure we should add such a %code option
> because, I presume, the same information can be obtained simply by
> checking the first character of the logged IP address for being '['.
> Said that, I am open to hearing arguments why it should be added.
>
>
> Cheers,
>
> Alex.
>

Thanks Alex,

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.

That's the whole point of "<" and ">".  These two qualifiers are linked to
the inside and outside IP versions, not the "l" in ">la" and "<la". That's
why I suggested a new variable "v" with two sides/directions (>/<).

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

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 []).

Scott
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: squid-users Digest, Vol 66, Issue 17

Amos Jeffries
Administrator
On 16/02/20 12:42 am, Scott wrote:

>> Date: Fri, 14 Feb 2020 11:03:50 -0500
>> From: Alex Rousskov
>>
>> On 2/14/20 10:36 AM, Scott wrote:
>>
>>> I know it's derivable by other means, but it would be nice to have a
>>> logformat format code that provided the client and server IP version numbers.
>>
>>> eg: >v for Client IP version (4 or 6) and <v for Server
>>
>>
>> Other than client and server, Squid can log a few other IP addresses,
>> including:
>>
>>     >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}
>>
>> FWIW, personally, I am not sure we should add such a %code option
>> because, I presume, the same information can be obtained simply by
>> checking the first character of the logged IP address for being '['.
>> Said that, I am open to hearing arguments why it should be added.
>>
>>
>> Cheers,
>>
>> Alex.
>>
>
> Thanks Alex,
>
> 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.
>

If you are using an IPv6 enabled Squid on a Hybrid-stack machine you may
notice that it does not have IPv4 listeners at all. Squid talks to IPv4
clients through IPv6 :: or a v4-mapping address.



> That's the whole point of "<" and ">".  These two qualifiers are linked to
> the inside and outside IP versions, not the "l" in ">la" and "<la". That's
> why I suggested a new variable "v" with two sides/directions (>/<).
>
> As to the suggestion that one differentiate IP versions by the signifier '[',
> from my experience "%>a" in logformat does NOT provide surrounding square
> brackets.

For Squid %<a / %>a codes the more correct sign is when the IP contains
a ':' it is IPv6 or later.


>
> 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 []).

IMO it would be better to implement the long outstanding request for
SNMP counters providing that information. No need to parse the logs then.

Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: squid-users Digest, Vol 66, Issue 17

Alex Rousskov
In reply to this post by Scott
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.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users