[squid-users] Muitple ISP client hashing

[Amos Jeffries]

On 5/09/2015 2:20 p.m., Lee Brown wrote:
> Hello,
> 
> I have multiple ISP's configured, working really nicely, snippet from
> config:
> 
> acl service_RLO src 10.1.10.175/32
> acl service_RLG src 10.1.10.0/24
> acl service_RLG src 10.1.200.0/24
> acl service_Guest src 10.1.3.0/24
> [cut]
> tcp_outgoing_address 10.1.248.1 service_RLO
> tcp_outgoing_address 10.1.248.2 service_RLG
> tcp_outgoing_address 10.1.248.4 service_Pst
> tcp_outgoing_address 10.1.248.5 service_Library
> tcp_outgoing_address 10.1.248.6 service_DP
> tcp_outgoing_address 10.1.248.3 service_Guest
> 
> I would like to add a new ISP and round-robin the src mapping to
> tcp_outgoing_address, such that, for example in the above service_RLG, I am
> looking to say, semantically:
> 
> tcp_outgoing_address 10.1.248.2, 10.1.248.9 service_RLG
> 
> Where the first IP matching service_RLG maps to 10.1.248.2, the next,
> different IP matching service_RLG maps to 10.1.248.9, etc.
> 
> I am not trying to split a single client over two ISP's, that can't work.

It can. HTTP messaging is stateless.

Any problems which occur are purely at the application layer outside of
HTTP.


> 
> I cannot see that this is possible with Squid (3.1.10), which BTW is in
> transparent proxy mode.

Please avoid the two-word term "transparent proxy". In relation to Squid
it has many very different meansing.

Is that a capital T and P as in TPROXY ?

Or a phrase missing its key words line "transparent NAT interception
proxy" ?

Or do you mean WPAD transparency ? or authentication single-sign on
transparency ? or one of those people who use the term to describe
reverse-proxy, privacy proxies, ... the term is overloaded into a mess.

> 
> I can't load balance the traffic out of Squid, for the above reason.

That is only true for TPROXY. Where Squid disables tcp_outgoing_address
and even your above config wont work.

With NAT interception (which I think you meant) there is no transparency
in your 3.1.

The very latest Squid _multiplex_ messages out whatever server
connections are free at the time and match both dst-IP and src-IP
requirements setup by the client inbound connection and
tcp_outgoing_address. Using ORIGINAL_DST to make it _appear_ more
transparent.


What you can't do is LB traffic volumes via round-robin. For the simple
fact that HTTP messages vary in size. So round-robin selection is
guaranteed to produce *im*balance.


> 
> I suppose I could hash the src ip to deliver traffic to two different ports
> in Squid, then use the port as the basis for the tcp_outgoing.  I feel this
> is sub-optimal though as two users may end up on a single ISP with the
> other ISP idle.


The "random" ACL type shines out as preferred method of LB via src-IP
mangling. There is imbalance, but it is not a certainty, relatively
short lived when it does occur, and is minor relative to the imbalances
coming from message sizes.


Or maybe you could just have one IP that Squid sets and use the proper
OS level LB feature to perform SNAT when that IP is used by Squid to
setup a new connection. It is far better able to deal with balancing
byte-wise than Squid.


Amos