Re: [squid-users] Multiple uplinks for different traffic types not working as intended: Help needed

> What you need to make (4) and (5) work is cache_peer_access deny rules
> for the peers where those domains are NOT allowed to go. Leaving other
> traffic unspecified for those peers.

Thank you very much for that input. I'll give this a try.

> > I guess in this scenario i could also replace all 4 proxy servers
> > with only one squid server with 3 different IP addresses and select
> > tcp_outgoing_address according Origin domain names.
> > The gateway would then choose the uplink according to squids
> > outgoing ip address.
>
> Indeed, MUCH simpler and faster. The thing to watch out for is whether
> doing that will limit your client traffic. If you are needing more
> uplinks simply to handle that you may not be able to merge the proxies
> without creating a bottleneck problem.

In our scenario the uplink bandwith is not that fast that the single
proxy solution would create a bottleneck.

> Its a bit confusing why you need such specific and different domain
> uplink logics in proxy1/2/3 and 0. If you can avoid that and make each
> proxy have the same tcp_outging_address selection, you avoid the
> bottleneck problems of one proxy and also the need for multiple
> listening addresses. All traffic can go to one of the proxies and the
> uplinks get used as needed.

Valid point. At the moment only proxy1 and proxy2 exists, all traffic
from proxy1 goes to uplink1, proxy2's traffic to uplink2. No ICP
communication between them. From this setup the above was derived which
adds proxy3 for uplink3 and proxy0 which decides which http traffic
flows to which proxy[1-3].

As i see now this is not the ideal setup: so thanks again for your
feedback that is much appreciated.

> NP: the configuration you have right now appears to be the model
> designed for use with proxy1/2/3 one each on the Internet side of
> uplinks 1/2/3 and proxy0 on the LAN side. Load balancing of proxy0 to
> its parents has the side effect of *connection*-balancing over the
> links, but decision happens at layer 7 (HTTP) instead of layer 3 (IP).

This is exactly how we want it to be. In essence with uplink3 in place
we want UL1 be utilized only for http traffic flowing to company-owned
web servers on the internet. uplink2 is for a handful of domains and
everything else will go over uplink3.

I'm aware that squid only does this for http traffic.

> > To solve b)-d) one could make squid listen on 3 additional ports
> > and choose tcp_outgoint_address according to acl myport, right?

> It could. But consider carefully why you need to determine uplink usage
> by *proxy* used. If it is really needed at all, can it be based better
> on client src address or something instead of the TCP port they happen
> to use?

You're right. My network scenario was simplified. In reality there will
be access_rules denying e.g. backoffice and sales people from accessing
these ports (or proxy[1-3] in above example). developers on the other
hand have to have the ability to select an explicit uplink of their
choosing. this will result in access rules allowing developers subnet
to access these extra listening ports in single squid solution or
proxy1-3 in multi squid solution.

> Basing it solely on the receiving port opens you to security problems
> with people finding the ports that work, and avoiding the limits.
> Preventing that requires additional firewall security to ensure specific
> TCP connections can't be made, and adds a lot of complexity to your
> switching fabric, firewalls, and proxy configs. Simply so you can load
> balance uplinks its far more trouble than its worth.

You're absolutely right.

> Load sharing multiple connections is a IP-layer feature of the kernel.
> Squid operates a few levels higher up the network stack. There are load
> balancing, uplink bonding, multi-homing solutions possibly available on
> your systems kernel already that work MUCH better than Squid when it
> comes to load-balancing. At best Squid performs connection-balancing,
> which is only properly balancing for TCP SYN packets. The bulk of TCP is
> in the data packets and thus can leave uplink usage looking *very*
> unbalanced from a traffic management perspetive.

I'm aware of this and know that traffic will not be balanced over all
uplinks evenly - but as said this is exactly what we want.

The gateway box has also policy based rules to forward non-http traffic
coming directly from user machines to specific uplinks.

I'll try the single squid solution as it seems to reduce complexity
dramatically.

Thank you for your valued feedback, Amos.

Yours,
Marcel.
Received on Sun Jun 03 2012 - 12:43:29 MDT