Archive for the ‘Cisco’ Category

WCCP with Cisco 877 and Squid

Tuesday, March 17th, 2009 by Steve

I just upgraded my Cisco 877 to the latest 12.4(24)T IOS, so I thought I’d have another go at getting WCCP to work.  Good news: it works!

Here’s my working configuration on the Cisco 877:

ip cef
ip wccp web-cache

interface Vlan1
ip wccp web-cache redirect in

This tells the router that web traffic coming into the Vlan1 interface is a candidate for caching. With WCCP, web-caches register themselves with the router, then the router forwards requests to them. This means that if the cache disappears, the router will forward web requests directly to the internet.

I’m using Debian, so I added this to /etc/network/interfaces (replace 1.2.3.4 with the router identifier shown on the cisco by “show ip wccp”. In my case this is the external internet-facing IP address):

auto gre1
iface gre1 inet static
address 127.0.0.2
netmask 255.255.255.255
pre-up ip tunnel add gre1 mode gre remote 1.2.3.4 local 10.0.20.1 dev eth1
post-down ip tunnel del gre1

And I added this line to my firewall script. You could add it to rc.local if you don’t have anywhere else to put it:

iptables -t nat -A PREROUTING -i gre1 -d 0/0 -p tcp –dport 80 -j DNAT –to-destination 10.0.20.1:3128

The only thing left now is the squid configuration. I specified the internal address of the cisco 877 here (10.0.20.254):

wccp2_router 10.0.20.254
wccp2_rebuild_wait on
wccp2_forwarding_method 1
wccp2_return_method 1
wccp2_assignment_method 1
wccp2_service standard 0
wccp2_address 10.0.20.1

Useful links:

Transparent webcaching on a Cisco 877

Sunday, October 28th, 2007 by Steve

After hours fighting with WCCP, i’ve given up and implemented the simpler solution: policy-based routing.

WCCP is a cisco protocol for managing web caches. It’s really quite slick, as it only forwards requests to the cache(s) when they are alive (and sending “i am here” messages to the router). If the cache service fails, the router passes web requests directly through. WCCP also automatically handles some of the fiddlier configuration, such as not mangling requests from the cache itself. Unfortunately I couldn’t get it to work.

My Cisco 877 is currently running the latest 12.4T IOS (12.4(15)T1). Some of the web guides I found suggested “known working” versions of 12.3 or 12.4 mainline IOS, but only 12.4T versions of IOS are available for the 877. This leaves a lot of variables, I might open a TAC case and get Cisco on the job.

Policy-based routing works, but it doesn’t gracefully handle cache failure like WCCP. On the Cisco 877:

no ip cef

access-list 101 deny tcp host 10.0.20.1 any eq www
access-list 101 permit tcp any any eq www

route-map proxy-redir permit 10
match ip address 101
set ip next-hop 10.0.20.1

interface Vlan1
ip policy route-map proxy-redir
ip route-cache policy

Where 10.0.20.1 is the IP address of the squid webcache.

This only works when I turn off CEF (no ip cef). When CEF is enabled, the first packet of the TCP connection (SYN) is forwarded from router to webcache, the webcache replies directly to the client (SYN|ACK), but the third packet from client (ACK) does not get forwarded by the router to the webcache. All connections time out.

When the policy-based routing is process switched the forwarding works as expected. All packets arrive at the webcache and the caching is transparent as expected. Fast-switched policy-based routing (ip route-cache policy) also works, which is an improvement on process-based, but the optimal solution would be CEF-based. I have a Cisco TAC case open to investigate this.

On the Linux 2.6 (debian Etch) squid server:

# Disable rp_filters
echo 0 > /proc/sys/net/ipv4/conf/default/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter

# transparent webcaching
iptables -t nat -A PREROUTING -s 10.0.20.0/24 -d ! 10.0.20.0/24 -p tcp –dport 80 -j DNAT –to-destination 10.0.20.1:3128

10.0.20.0/24 is the subnet to cache, and 10.0.20.1 is the IP address of the webcache.

That’s it. HTTP requests are transparently forwarded to the squid server and cached.

I found these resources helpful when trying to get WCCP working:

And these were useful for policy based routing: