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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
