Steve Glendinning

I just applied a hotfix to my XenSource virtual servers, which caused all the virtual machines to be suspended & resumed (while the xen host rebooted).  This caused a problem on the VMs I’ve upgraded to Debian Lenny: These messages were repeatedly logged:

clocksource/0: Time went backwards: ret=18f26176a5 delta=-8292949932632971 shadow=18e9e0b4b9 offset=880c4ce

This message wasn’t “harmless” – it caused TCP connections to break, so ssh was practically unusable.

The immediate solution: using the XenCenter console, forcefully reboot the affected VM. That’s “force shutdown”, followed by “start”. I tried the simple “reboot” option, but it wouldn’t shut down (probably because it was confused over the time). VMs are now back up and there’s no sign of time going backwards.

It seems this was triggered by suspending & resuming machines running the Debian Lenny kernel. Other VMs which are still running the 2.6.18 based XenSource kernels survived suspend/resume ok.

The actual cause is documented here, here, here & here. I think I’ll be following that advice and decoupling my VM clocks from the host (using NTP to keep them all in sync the old-fashioned way).

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:

• http://www.usenet-forums.com/squid-users/247645-wccp-gre-redirect-target-failed-solution.html
• http://wiki.squid-cache.org/SquidFaq/InterceptionProxy
• http://www.cisco.com/public/news_training/itsnews/tech/chalktalk/200806.html