Henrik Nordstrom wrote:
> On Wed, 23 Feb 2005, Jesse Guardiani wrote:
>
>> #sh ip wccp web-cache detail
>> WCCP Cache-Engine information:
>> IP Address: 192.168.10.2
>> Protocol Version: 2.0
>> State: Usable
>> Initial Hash Info: 00000000000000000000000000000000
>> 00000000000000000000000000000000
>> Assigned Hash Info: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
>> FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
>> Hash Allotment: 256 (100.00%)
>> Packets Redirected: 509
>> Connect Time: 00:30:51
>
> Good.
>
>> # iptunnel
>> gre0: gre/ip remote any local any ttl inherit nopmtudisc
>> gre1: gre/ip remote 192.168.10.1 local 192.168.10.2 dev eth0 ttl
>> inherit
>
> OK, I think.. (not sure about the first..)
>
>> # iptables -t nat -L -v
>> Chain PREROUTING (policy ACCEPT 158 packets, 20654 bytes)
>> pkts bytes target prot opt in out source
>> destination
>> 0 0 REDIRECT tcp -- eth0:22 any anywhere
>> anywhere tcp dpt:www redir ports 3128
>> 0 0 REDIRECT tcp -- eth0 any anywhere
>> anywhere tcp dpt:www redir ports 3128
>
> Hmm.. the packets will be coming in on the gre device, not eth0. At least
> unless the WCCPv2 patch is configured to send the redirected packets by
> direct routing without GRE/WCCPv2 encapsulation.
Ah ha! I had tried that when I was testing WCCPv1, but forgot to try
it with WCCPv2. I'm now seeing hits on my iptables counters:
# iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 309 packets, 42707 bytes)
pkts bytes target prot opt in out source destination
0 0 REDIRECT tcp -- eth0:22 any anywhere anywhere tcp dpt:www redir ports 3128
0 0 REDIRECT tcp -- eth0 any anywhere anywhere tcp dpt:www redir ports 3128
31 1780 REDIRECT tcp -- gre1 any anywhere anywhere tcp dpt:www redir ports 3128
Chain POSTROUTING (policy ACCEPT 2212 packets, 146K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
[...]
>> Shouldn't the cisco be marking the cache as unusable or block
>> the web traffic?
OK. It's blocking the traffic now. I try to access a page on the
client and the browser just spins. I'm not seeing any new entries
in my squid access log, but the counters in iptables are incrementing
as shown above.
My guess is that since the squid box is on the same subnet as the
client box, the cisco is looping port 80 traffic from the squid
back to the squid. Does that sound possible? Again, I'm not seeing
anything in access.log though. What do you think?
--
Jesse Guardiani, Systems Administrator
WingNET Internet Services,
P.O. Box 2605 // Cleveland, TN 37320-2605
423-559-LINK (v) 423-559-5145 (f)
http://www.wingnet.net
