Whether ’tis nobler in the network to suffer un-accelerated traffic during an outage or to take arms in the form of Policy Based Routing.

When you decide to†deploy†Citrix Branch Repeaters (CBR) you have to†deploy†at either end of the WAN to accelerate and compress traffic between these endpoints. Therefore it would seem sensible to have some resiliance in the design to at a minimum protect the hub in a hub and spoke topology.

Deployment Models

There are 3†deployment†models that I would consider, there are actually a few more available like proxy redirect, but it is not relvant to where I want to go in this post.

1. Inline mode ñ sits on the wire and accelerates traffic flowing between the Ethernet ports.
2. WCCP mode ñ we use WCCP to pull traffic towards the device. We can provide an active/standby solution.
3. Virtual Inline mode ñ The router sends the traffic to the WAN appliance (using PBR) and the appliance accelerates and sends it back to its default gateway.†We can provide an active/standby solution.

You should also be aware the CBR needs to accelerate the conversation from the start and cannot kick-in halfway through, therefore the longer the CBR has been offline the more conversations will be missed that cannot be†accelerated until the conversation is restarted.

Inline Mode

There are a few problems with this when thinking about†resilience.

1. As stated above CBR works in pairs at either end of the WAN and requires symetric routing, therefore you would have to ensure that data passes through Hub1 to Spoke1 and back from Spoke1 to Hub 1. Then you have to figure out how to do Hub1 to Spoke 2 and Spoke2 to Hub 1 or perhaps Hub2 to Spoke2 and Spoke 2 to Hub 2. Yes it gets messy!
2. If the system fails-open and leaves traffic un-accelerated and un-compressed for any†length†of time, you will have a performance hit on the WAN, most likely at the spoke site as this is typically where the bandwidth with be tune down to match the CBR accelerated traffic profile.
3. To replace the system you have to disconnect an inline connection which can always be problematic trying to arrange downtime.
4. I cannot see any simple way of providing†resiliency†if an appliance fails, albeit it fails open with no acceleration.

WCCP mode

This seem sensible at the outset, we use WCCP to forward to the CBR based on the WCCP requests from the CBR to the Router and this can be done with hardware switching (depending on the device) so it is fast.

Here is what you need to know about the CBR setup with WCCP when you deploy a pair of CBRs in HA mode for WCCP

1. They run as†Active/Standby.
2. There is no stateful†fail-over.
3. Packets once accelerated are return to the WCCP Router that sent them to the CBR.
4. At Fail-over, the Standby now†becoming†Active needs to negotiate WCCP with the router once VRRP has†failed-over.

In my testing on 3750-X I have seen this consistently take 90 seconds before WCCP is established and traffic is being accelerated again and this was with WCCP settings hardcoded on the CBR.

Virtual Inline Mode

This works very similar to WCCP, except rather than using WCCP to direct the traffic we use PBR to direct traffic to the CBR. The thing here is if a router can do WCCP in hardware then it is very likely to be able to do PBR in hardware, so from a†performance†perspective I cannot determine the advantage of WCCP.†Allegedly†the configuration on the router is simpler in WCCP, but here’s what you need to know.

1. They run as†Active/Standby.
2. There is no stateful†fail-over.
3. Packets once accelerated are sent to the CBR default gateway address.(This is the key difference to WCCP)
4. PBR can send to the VRRP address of the pair, therefore failover only takes as long as VRRP to switch over.

In my testing on 3750-X I have seen this take < 4 seconds before VRRP on the CBR has failed over and traffic is being accelerated again.

Conclusion

WCCP was developed by Cisco for redirecting and load-balancing web traffic across an array of web proxy servers and in version 2 has been expanded to work with other protocol. In this case the where load balancing is not an option due to the active/standby nature of the deployment scenario I can not †see a strong need for WCCP; in†addition†to this is the fact that your fail-over will take over 1 minute before it is†capable†of†accelerating†traffic again.

The advantage that WCCP has over PBR is that it will send the accelerated packets back to the originating routers, therefore if you have 2 WAN connection it can easily use both, where as the PBR solution is alway going to prefer a single router.

For me PBR seems like a more sensible choice for†deploying†CBR with†resilience†unless there is a need to balance the traffic load across multiple egress points.