Computer Ramblings

WCCP Across a Firewall – Part 2

I still hate WCCP. I recently had to revisit my WCCP implementation documented in a previous post because of an outage breaking the WCCP connection between my router and my Bluecoat. After we repaired the problem, I noticed that the WCCP connection was no longer working as it was previously to the problem. Since no changes were made in in the recovery process, which was a reboot of a device, I could not figure out why WCCP was no longer working. Long story short, I noticed that the source interface of the GRE tunnel changed and it was not being allowed through the firewall.

We made some additional engineering changes to this router over time. We added a new network interface to the router but WCCP was not affected with the changes. When the WCCP connection was broken, the router negoiated the GRE tunnel using a new source for the tunnel. After much searching on the Cisco site I found the white paper below spelling out what I believed to be the issue with the source of the GRE tunnel being redefined on the router. I added a loopback interface on the router and removed and reapplied the WCCP configuration on the router. As expected, the new source for the GRE tunnel was the loopback address. Changes were made on the Bluecoats and the firewalls to allow traffic to traverse using the loopback address and full WCCP operation was restored.

From White Paper:

When using GRE encapsulation for WCCP redirection, the router uses the router ID IP address as its source IP address. The router ID IP address is the highest loopback address on the router, or if the loopback interface is not configured, the router ID IP address is the highest address of the physical interfaces.

Source:
Deploying WAAS Using WCCP Paper v3

Great Virtualization Quote

I read a great article on virtualization and redundancy. The quote below was taken from the posting and I thought it spoke volumes. Enjoy.

The Probability of a server having an outage is part hardware failure but mostly administrator induced failure. Having a huge number of components, less automation, more variance in configurations, poor process and system controls: these are the things that will cause an outage to a server. The Mean Time Between Failure (MTBF) for high-end components are measured in years. The Mean Time Between Cock-up (MTBC) varies depending on how good your staff are at IT.

The Impact of a server having an outage is really simple to calculate and mitigate and you need to think of the 3Rs: Redundancy, Resilience and Recovery.

· Redundancy is duplicating components, including the application. Running multiple webservers that do the same job and spreading these across physical servers means that when one server dies, the others take up the load. Make sure you have redundant capacity for your workload (e.g. N+1) and the impact is not an outage, just a reduction in excess capacity.

· Resilience is how well you can absorb an outage by restarting servers and applications in the same site.

· Recovery is the more serious disaster end of the scale and involves recovering services at a remote site.

http://viewyonder.com/2010/03/28/dont-be-a-chicken-cram-your-eggs-into-vsphere-on-ucs/

One Arm Load Balancing on the ACE

Below is a sample configuration which will use the ACE module to provide load balancing of real servers through the network.  In this example, the ACE NAT’s all calls from a client to get traffic back to the ACE so that the ACE sees the whole flow of traffic.  A quick diagram is also attached.

ACE-1/onearm# sho run
Generating configuration….

access-list ALLOW line 8 extended permit ip any any
access-list ALLOW line 16 extended permit icmp any any

rserver host one
ip address 2.2.2.2
inservice
rserver host two
ip address 2.2.2.3
inservice

serverfarm host web
rserver one
inservice
rserver two
inservice

class-map match-all slb-vip
2 match virtual-address 1.1.1.254 any

policy-map type management first-match remote-access
class class-default
permit

policy-map type loadbalance first-match slb
class class-default
serverfarm web

policy-map multi-match client-vips
class slb-vip
loadbalance vip inservice
loadbalance policy slb
nat dynamic 1 vlan 100

interface vlan 100
description “Client-Server VLAN”
ip address 1.1.1.2 255.255.255.0
access-group input ALLOW
service-policy input client-vips
service-policy input remote-access
nat-pool 1 1.1.1.20 1.1.1.21 netmask 255.255.255.0 pat
no shutdown

ip route 0.0.0.0 0.0.0.0 1.1.1.1