Re: [squid-users] Re: Problem with squid tcp_outgoing_address

2014-03-11 Thread k simon

The second question:
  request_header_access and tcp_outgoing_address, who will be issued 
first ?
  For example, I want use tcp_outgoing_address based on a request 
header , then delete the header before it really sent out?


Simon

于 14-3-11 12:12, k simon 写道:

Hi,Amos,
   As tcp_outgoing_address support fast group ACL, can I use ACL base on
some header?

Regards
Simon



于 14-3-10 19:20, Amos Jeffries 写道:

On 10/03/2014 8:56 p.m., babajaga wrote:

As I have a similar problem, just using this thread:
How to use tcp_outgoing_address for load balancing (round robin) ?

My idea was to write an ACL-helper doing the round-robin, which would be
very easy; but how to detect a failed WAN-connection within
ACL-helper ?)


(One local interface, 3 WAN-interfaces to different ISPs, for
redundancy and
balanced load sharing)


Simple answer is that tcp_outgoing_address is the wrong place for that.
Use the OS routing/firewall rules instead.


There are a few issues:

1) tcp_outgoing_address is a fast group ACL. Meaning it cannot use
external ACL helpers directly, must rely on a cached result from some
previous lookup of the helper.

2) In the recent Squid releases you can use the random type ACL to
spread the outgoing connections between a lit of tcp_outgoing_address
values.
   2a) tcp_outgoing_address is checked for every *potential* connection.
So load balancing using it does not work for any domains with multiple
IPs.
   2b) the OS is free to ignore tcp_outgoing_address if its rules assign
an IP address (ie source-NAT).
   2c) the choice of an outgoing IP address in no way limits what route
the packets may use. The OS routing rues need to be configured
explicitly for that. So may as well configure the load balancing there
to begin with.


Also the kernel already has all available information about up/down
state of NIC. So trying to get that into Squid is a lot of extra work
and latency on all connections for a very little benefit gain on
uncommon occasions.


Amos



[squid-users] Re: Problem with squid tcp_outgoing_address

2014-03-10 Thread babajaga
As I have a similar problem, just using this thread:
How to use tcp_outgoing_address for load balancing (round robin) ?

My idea was to write an ACL-helper doing the round-robin, which would be
very easy; but how to detect a failed WAN-connection within ACL-helper ?)


(One local interface, 3 WAN-interfaces to different ISPs, for redundancy and
balanced load sharing)





--
View this message in context: 
http://squid-web-proxy-cache.1019090.n4.nabble.com/Problem-with-squid-tcp-outgoing-address-tp4657445p4665113.html
Sent from the Squid - Users mailing list archive at Nabble.com.


Re: [squid-users] Re: Problem with squid tcp_outgoing_address

2014-03-10 Thread Amos Jeffries
On 10/03/2014 8:56 p.m., babajaga wrote:
 As I have a similar problem, just using this thread:
 How to use tcp_outgoing_address for load balancing (round robin) ?
 
 My idea was to write an ACL-helper doing the round-robin, which would be
 very easy; but how to detect a failed WAN-connection within ACL-helper ?)
 
 
 (One local interface, 3 WAN-interfaces to different ISPs, for redundancy and
 balanced load sharing)

Simple answer is that tcp_outgoing_address is the wrong place for that.
Use the OS routing/firewall rules instead.


There are a few issues:

1) tcp_outgoing_address is a fast group ACL. Meaning it cannot use
external ACL helpers directly, must rely on a cached result from some
previous lookup of the helper.

2) In the recent Squid releases you can use the random type ACL to
spread the outgoing connections between a lit of tcp_outgoing_address
values.
  2a) tcp_outgoing_address is checked for every *potential* connection.
So load balancing using it does not work for any domains with multiple IPs.
  2b) the OS is free to ignore tcp_outgoing_address if its rules assign
an IP address (ie source-NAT).
  2c) the choice of an outgoing IP address in no way limits what route
the packets may use. The OS routing rues need to be configured
explicitly for that. So may as well configure the load balancing there
to begin with.


Also the kernel already has all available information about up/down
state of NIC. So trying to get that into Squid is a lot of extra work
and latency on all connections for a very little benefit gain on
uncommon occasions.


Amos


Re: [squid-users] Re: Problem with squid tcp_outgoing_address

2014-03-10 Thread k simon

Hi,Amos,
  As tcp_outgoing_address support fast group ACL, can I use ACL base on 
some header?


Regards
Simon



于 14-3-10 19:20, Amos Jeffries 写道:

On 10/03/2014 8:56 p.m., babajaga wrote:

As I have a similar problem, just using this thread:
How to use tcp_outgoing_address for load balancing (round robin) ?

My idea was to write an ACL-helper doing the round-robin, which would be
very easy; but how to detect a failed WAN-connection within ACL-helper ?)


(One local interface, 3 WAN-interfaces to different ISPs, for redundancy and
balanced load sharing)


Simple answer is that tcp_outgoing_address is the wrong place for that.
Use the OS routing/firewall rules instead.


There are a few issues:

1) tcp_outgoing_address is a fast group ACL. Meaning it cannot use
external ACL helpers directly, must rely on a cached result from some
previous lookup of the helper.

2) In the recent Squid releases you can use the random type ACL to
spread the outgoing connections between a lit of tcp_outgoing_address
values.
   2a) tcp_outgoing_address is checked for every *potential* connection.
So load balancing using it does not work for any domains with multiple IPs.
   2b) the OS is free to ignore tcp_outgoing_address if its rules assign
an IP address (ie source-NAT).
   2c) the choice of an outgoing IP address in no way limits what route
the packets may use. The OS routing rues need to be configured
explicitly for that. So may as well configure the load balancing there
to begin with.


Also the kernel already has all available information about up/down
state of NIC. So trying to get that into Squid is a lot of extra work
and latency on all connections for a very little benefit gain on
uncommon occasions.


Amos