This doc describes how to configure an Alteon/Nortel Acedirector 4 to support Server Load Balancing (SLB) and/or Interception Caching (IC) with Squid proxy servers.
Our configuration comprised of :
Original of this document is available from http://www.pipeline.com.au/staff/mbowe/isp/SLB_IC_AD4_Squid.htm
You need to give the Acedirector an IP address so that you can access it for telnet / SSH / SNMP etc
/cfg/ip/if 1 addr xxx.xxx.xxx.40 ena
Server groups are required by both the SLB and IC functions of the Acedirector.
DEFINE THE REAL SERVERS
Our first configuration step is to tell the Acedirector the IP addresses of each of the Squid servers that will make up the group.
In our example, we have four Squid servers that are going to make up the server group :
/cfg/slb/real 1 rip xxx.xxx.xxx.10 name proxy1 ena /cfg/slb/real 2 rip xxx.xxx.xxx.11 name proxy2 ena /cfg/slb/real 3 rip xxx.xxx.xxx.12 name proxy3 ena /cfg/slb/real 4 rip xxx.xxx.xxx.13 name proxy4 enaWe have attached names to these entries. The names are not used by the Acedirector, they are just optional labels to make it easier for us to remember what server is being referred to.
PUT THE REAL SERVERS INTO A GROUP
Now we need to define a group to put all the Squid servers into. We will add the four Squid servers that we defined above into "group 1"
/cfg/slb/group 1 add 1 add 2 add 3 add 4 name Squid-proxies metric hashYou can see that we have given the group a name. This is just an optional label to help us remember what the group is used for.
Any traffic that arrives for this group will be be distributed amongst the group members based on the "metric" that you select. There are various metric types available that share the traffic using different algorithms. From my experience, I have found the "hash" metric to be the most suitable for use with Squid caches.
Acedirector groups provide the following benefits:
- Increased reliability - if one of the members of the group fails, the others can take up the additional load.
- Improved performance - the load is balanced across all the members of the group. Additional servers can be added at any time to increase processing power.
- Ease of maintenance - servers can be added or removed at any time without interruption to services.
OK, now we have configured group, we can setup SLB and/or IC
WHAT IS SLB?
Server load balancing is where you create a virtual server IP address, and then have the Acedirector distribute traffic that was destined to this address through to a nominated server group.
You would use DNS to map this virtual IP to a friendly DNS name eg "proxy.yourdomain.com"
WHEN WOULD YOU WANT TO USE SLB WITH SQUID?
Example 1
SLB is very handy when you have already got a large number of web browsers deployed that have been set to use particular Squid server (eg proxy.yourdomain.com port 8080). SLB will improve performance and reliability by allowing you to install multiple Squids, and you won't have to change any settings in the client's web browser (which would be very time consuming).
An Acedirector configured for SLB is a much more powerful than trying to do a similar thing with round-robin DNS.
Example 2
Before I installed our Acedirector on my network, most of our web browser's had been configured to use autoproxy configuration (eg www.ourdomain.com/proxy.pac). The we had programmed the proxy.pac with some elaborate javascript to try and share traffic around amongst our existing Squids.
Once we installed our Acedirector with SLB support, we modified the proxy.pac file to just return the SLB virtual server's address (proxy.ourdomain.com port 8080). That way no reconfiguration was required in the client's browsers, and they had immediate access to the superiour SLB functionality of the Acedirector.
DEFINE THE VIRTUAL SERVER
Our first step in configuring SLB is to choose an IP address that we will use for the virtual server. In our example it will be xxx.xxx.xxx.20
Next we need to define what port number the virtual server is to listen on. In our example it will be TCP port 8080
Next we tell the Acedirector that it is to forward any matching traffic through to server group 1
/cfg/slb/virt 1 vip xxx.xxx.xxx.20 service 8080 group 1 enaThe Acedirector monitors the health of each real server in the nominated group by regularly opening a TCP connection to the nominated service port (8080)
DEFINE WHICH ACEDIRECTOR PORTS HAVE CLIENTS AND/OR SERVERS CONNECTED
For the SLB functions of the Acedirector to work correctly, the Acedirector needs to know which of it's ethernet ports have clients and/or servers connected. (In our example, "clients" are web browsers, and "servers" are Squid proxies)
The Acedirector 4 has eight ethernet ports. In our example, we have plugged the four Squid servers into ports 1, 2, 3 and 4. Ports 5 and 6 are unused. Our local LAN connects to port 7. Our Internet gateway router connects to port 8.
(Note that you aren't limited to having only one server per port. Also clients and servers could be connected to the same port if you choose. You just need to make sure you enable the appropriate combination of client and server processing in the Acedirector depending on the mix of computers attached to each particular port.)
/cfg/slb/port 1 name proxy1 server ena client dis /cfg/slb/port 2 name proxy2 server ena client dis /cfg/slb/port 3 name proxy3 server ena client dis /cfg/slb/port 4 name proxy4 server ena client dis /cfg/slb/port 5 name not-in-use server dis client dis /cfg/slb/port 6 name not-in-use server dis client dis /cfg/slb/port 7 name LocalLAN server dis client ena /cfg/slb/port 8 name Internet server dis client disYou will notice that we have given each port a name. This is just an optional label to help us remember what devices are connected to each port.
ENABLE DIRECT ACCESS TO THE SERVERS IF REQUIRED
By default, the Acedirector does not allow "direct" access to the real server's SLB'ed services.
eg. you will no longer be able to set your browser's proxy to be "proxy1.yourdomain.com port 8080". You would be forced to use the virtual server name "proxy.yourdomain.com port 8080"
If you need direct access (which I think is quite handy, particularly for fault-finding...), then issue the following command :
/cfg/slb/adv/direct ena
TURN ON THE SLB FUNCTIONS ON THE ACEDIRECTOR
Now, to enable the SLB functionality on the Acedirector, issue the following commands
/cfg/slb on apply cur
SLB CONCLUSIONS
Dont forget to add an entry to your DNS eg proxy.yourdomain.com IN A xxx.xxx.xxx.20
At this point we have completed the server load balancing part of the configuration. If the users then configure their web browsers for manual proxies and specify proxy.yourdomain.com port 8080, they will benefit from the Acedirector's SLB features.
If you already have your corporate LAN setup this way with browsers locked down with manual proxies, then your job is now done. However for most admins, it is even better to have interception caching enabled as well, as you can then intercept all web traffic regardless of whether the users have proxies enabled or not. Read on for more info....
IC requires us to configure some filters on the Acedirector so that it knows what traffic to intercept, and where to send it.
In our example we are going to be intercepting web browser traffic that is originating from our local LAN, and redirecting it through to our Squid server group.
To get IC to operate correctly, specific configuration is required on both the Acedirector and on the Squid servers
CONFIGURE THE ACEDIRECTOR
On our example network, we have got Apache web server software running on the Squid proxy servers. Apache is used to display pwebstats reports, and also the output of Squid's cachemgr.cgi scripts. To make sure we continue to allow direct access to port 80 on the local Squid servers, we will use filter number 1 thru 4 to allow this traffic through without interception.
/cfg/slb/filt 1 sip any dip xxx.xxx.xxx.10 dmask 255.255.255.255 proto tcp sport any dport http action allow ena /cfg/slb/filt 2 sip any dip xxx.xxx.xxx.11 dmask 255.255.255.255 proto tcp sport any dport http action allow ena /cfg/slb/filt 3 sip any dip xxx.xxx.xxx.12 dmask 255.255.255.255 proto tcp sport any dport http action allow ena /cfg/slb/filt 4 sip any dip xxx.xxx.xxx.13 dmask 255.255.255.255 proto tcp sport any dport http action allow enaFilter 10 tells the Acedirector to intercept web browser port 80 traffic, and redirect it to our server group 1
/cfg/slb/filt 10 sip any dip any proto tcp sport any dport http action redir rport 8080 group 1 enaIMPORTANT : From reading the Acedirector docs, and from looking at the command above, you would assume that the Acedirector redirects the intercepted traffic through to port 8080 on the Squid server. However this is NOT the case. The traffic is certainly redirected it to the Squid server, but the destination port remains unchanged (port 80). The "rport 8080" command is actually only used to tell the Acedirector what port the Squid software is running on, so that the Acedirector can perform health check monitoring on this port.
Filter 224 is the last possible filter number, so put a catchall entry here that allows all other remaining traffic through without interception
/cfg/slb/filt 224 sip any dip any proto any action allow enaOK, now that we have written the filters, we need to tell the Acedirector which of it's ethernet ports will have the filters installed. In our example, all our web browsing users are on the local LAN which is attached to the port 7 :
/cfg/slb/port 7
add 1
add 2
add 3
add 4
add 10
add 224
filt enableEnable the IC functionality in the Acedirector
/cfg/slb
on
apply
curThe Acedirector is now configured to intercept web browser traffic from port 7 and redirect it to the Squid servers. Next we need to configure the Squids to accept and correctly process this redirected traffic
CONFIGURE THE SQUID SERVERS
The Acedirector redirects traffic by altering the destination MAC address of the packet to be the MAC address of the Squid server. When the packet arrives at the Squid server the original source and destination IP addresses are still intact. Thus the packet's destination IP address will still contain the IP address of the web site that the client is wanting to view. The original destination port field (80) is also still intact (refer to yellow notes above).
We use some ipchains rules on the Squid server to inspect the destination address field of all incoming packets and then process the packet accordingly :
- If the packet was addressed to 127.0.0.1:80, then let it through as normal (ie this packet wasn't interception traffic)
- If the packet was addressed to the IP address of this Squid server, then let it through as normal (ie this packet wasn't interception traffic)
- All other port 80 traffic that has arrived at this server must interception traffic, so redirect it through to the Squid software which is running on port 8080.
A sample ipchains configuration for "proxy1" (which has an IP address of xxx.xxx.xxx.10).
#-- Accept any incoming non-interception port 80 traffic -A input -s 0/0 -d 127.0.0.1/32 80 -p tcp -y -j ACCEPT -A input -s 0/0 -d xxx.xxx.xxx.10/32 80 -p tcp -y -j ACCEPT #-- Accept any interception traffic that is arriving on port 80 #-- and redirect it through to port 8080 for processing -A input -s 0/0 -d 0/0 80 -p tcp -y -j REDIRECT 8080(On RedHat 7.x, this ipchains configuration is stored at /etc/sysconfig/ipchains)
Once you have modified the rules, dont forget to restart the ipchains software so the new rules are enabled :
/etc/rc.d/init.d/ipchains restartThe Squid server software will now be receiving the interception traffic. The Squid software will notice that the destination IP address of the packets are not the same as the local IP address. Squid classifies this sort of traffic as "httpd_accellerator". We need to give the Squid server some extra commands so that it knows how to correctly process this particular type of traffic.
The relevant parts of the squid.conf for enabling httpd_accellerator mode for IC are :
httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header onOnce you have added these configuration lines, make sure you remember to tell squid to re-read its configuration :
squid -k reconfAlso, don't forget to repeat these same ipchains/squid configuration steps for each squid machine in your server group!
Back to Michael's ISP Links page
Last edited
29-Dec-2006
Please send me your feedback!