I am trying to set up Squid 2.5-STABLE3 as a transparent proxy with a
Cisco 7204 VXR (running IOS 12.2(6))and am running across a maddening
problem - works in test network, doesn't work in production network.
I have read the FAQ as well as searched the lists. I have tried both
the ip_no_pmtu_disc and setting the MTU of eth0 back to 1476, and
neither worked (nor did I expect them to as when it doesn't work, it
doesn't work for redirection as well as it doesn't work hitting the
proxy directly).
I am using the ip_wccp module as described in the FAQ. Have tried
ip_gre however ip_wccp just seems more straightforward to me.
When it's not working, doing a "sh ip wccp web-cache" on the router will
show the redirected packet counter incrementing, access.log is logging
client accesses, cache.log shows no abnormalities, and messages shows no
abnormalities (i.e. if I wasn't sitting at the client everything would
look like it's working), top shows the box barely breaking a sweat
(squid taking < 1% of CPU), but the clients never get pages and
eventually time out. Did a sniff of the segment (with ethereal) that
the Squid box is on and it appears that redirected requests are going on
the segment, but Squid never (or more accurately very rarely) goes out
to get the data for the requests. (Conversely, in the test network, you
see the redirected request, Squid going out to get the data, the remote
server responding, and Squid sending the data back - this only happens
for a minute number of the redirected requests in the production
network). Once I disable the redirection from the Cisco side, clients
(test, small number) hitting the squid cache directly work once again
(no further intervention required).
The only difference between the production and test networks (other than
client load) is the production network is redirecting off of atm1/0
while the test network is redirecting off of fa0/0 (and the requisite
addressing/configuration changes). I don't believe that to be cause of
the functionality problem as in the production network I do see the
packets being redirected to Squid.
The box is a dual P4 XEON 2.4G, hyperthreading (Linux sees "4"
processors) with 3GB RAM and 3 36GB U320 SCSI drives. Linux 2.4.20,
iptables 1.2.8, squid 2.5STABLE3. I do have fairly restrictive firewall
rules, however they are consistent between the production and test
environments therefore I don't at this point believe the issue lies there.
Squid was compiled with: --prefix=/usr/local/squid
--enable-storeio=ufs,diskd --enable-removal-policies=lru,heap
--enable-wccp --disable-ident-lookups --enable-truncate
--enable-underscores --enable-linux-netfilter
squid.conf excerpt:
http_port (IP Address eth0):8080
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
wccp_router (router's fa0/0 same subnet)
iptables redirect:
iptables -t nat -A PREROUTING -p TCP -i eth0 --dport 80 -s (myIPspace)
-j REDIRECT --to-port 8080
Cache partition mount options:
LABEL=/var/squid/0 /var/squid/0 ext3
defaults,noatime,noexec,nosuid 1 2
LABEL=/var/squid/1 /var/squid/1 ext3
defaults,noatime,noexec,nosuid 1 2
LABEL=/var/squid/2 /var/squid/2 ext3
defaults,noatime,noexec,nosuid 1 2
router configuration:
ip wccp version 1
ip wccp web-cache
(within the interface) ip wccp web-cache redirect out
If I didn't know any better it would appear to be purely a load related
issue (within Squid, as the box doesn't appear to be doing anything) but
I know there has to be people out there throwing more at it than I am
(between 500-600 potential clients when I attempted to insert into the
production environment).
Lastly, in the production environment (prior to trying Squid) I did have
a Cisco Cache Engine 590 running WCCPv2 against the same router (I did
configure the router for WCCPv1 when removing this cache and inserting
Squid) and working... So I know the production router will handle the
redirection properly...
Any ideas on how to fix or where to look for more info to debug this?
Could it purely be a performance tuning/recompile issue?
Received on Sun Aug 03 2003 - 23:53:33 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:18:33 MST