Integrating Accelerators into the
Network
To understand how accelerators
coexist with the foundational network technologies for visibility, control, and
resource alignment, it is also important to understand how accelerators
integrate into the network. Integrating accelerators includes deploying
accelerators and delivering to the accelerator traffic that should be optimized
or needs to be unoptimized. In essence, deploying an accelerator requires that
traffic somehow be given to the accelerator, and that the traffic optimized by
the accelerator somehow be delivered to the distant accelerator on the other
side of the WAN. This integration can be achieved physically or logically and
can leverage network-integrated or nonintegrated mechanisms.
Physical Integration
Physical integration refers to the
ability of an accelerator to be deployed directly into a pre-existing network
device. This allows IT organizations to collapse the number of devices necessary
in the physical infrastructure, which helps to minimize costs related to
management, support, and power.
In most cases, physical integration
refers to integration directly into the router using modules that have
accelerator capabilities. With physical integration, the network device could
use an integration protocol such as Web Cache Control Protocol (WCCP) or Cisco
Policy Based Routing (discussed in the next section, "Logical Integration"), or another mechanism for routing traffic
through the onboard accelerator.
In other cases, physical integration
refers to integration of the accelerator directly between the WAN router and the
LAN switch using a network card that supports fail-to-wire operation. This mode
of physical integration, commonly referred to as physical inline, allows the
accelerator to be deployed directly in the network path, and removed from the
network path virtually should a failure occur. This is accomplished using the
fail-to-wire network card, which physically closes the connection between the
two network cables if a software, hardware, or power failure is encountered.
With physical inline, the accelerator
sits physically between the WAN router and the LAN switch and sees all traffic
traversing that connection. Physical inline provides the simplest, yet least
elegant, means of integrating an accelerator into a network architecture,
because it requires changing of cables and generally lacks the same levels of
scalability and high availability as provided by other integration mechanisms
such as WCCPv2 (discussed in the next section). Physical inline also poses the
risk that a failure condition encountered by the device that is not recognized
by the inline card hardware or driver might not immediately trigger a
fail-through condition on the card, thereby preventing network traffic from
passing through the device.
Figure 3-21 shows an example of deploying an accelerator as an integrated
module within a branch office router.
Figure 3-22 shows an example
of deploying an accelerator physically inline between the branch office LAN
switch and router.
Logical Integration
Logical integration, also called network interception, refers
to the use of networking protocols, features, or devices to ensure that traffic
is routed through the accelerator in such a way that optimization and
de-optimization can be applied to those traffic flows. The three most common
means of logical integration through network interception include the
following:
-
Web Cache Control Protocol version 2
(WCCPv2)
-
Policy Based Routing (PBR)
-
Interaction with a dedicated or shared
load-balancing device such as a server load balancer (SLB)
Web Cache Control Protocol v2
WCCPv2 is a control protocol that allows a
WCCP child device such as an accelerator to connect with a network device such
as a router, also known as a WCCP server. The result of this connection is that the accelerator
notifies the network of the types of traffic it is able to handle so that the
network device can intercept traffic (remove it from the normal forwarding path)
and forward that traffic to a WCCPv2 child device if the specified type of
traffic is encountered. The router maintains a service group of accelerator devices and
balances the distribution of workload across the devices within that service
group.
WCCPv2 supports up to 32 routers and
32 child devices being joined within the same service group, which allows for
near-linear scalability and performance increases as additional accelerator
devices are joined into the service group. WCCPv2 also provides fail-through
operation; if no service group child devices are present, traffic is not
intercepted and is serviced by the router without any form of redirection. With
WCCPv2, devices can be dynamically added to or removed from service groups with
little to no interruption of service. Because WCCPv2 provides off-path
integration, scalability, and load-balancing, it is considered the most
desirable architecture for integrating accelerators into a network location.
Figure 3-23 shows an example of how accelerators are deployed within a
location where WCCPv2 is configured.

Policy Based Routing
Policy Based Routing (PBR) is a
mechanism implemented in network devices such as routers that allows network
administrators to apply a policy to how specific types of traffic should be
routed through the network based on something other than the destination IP
address. PBR can use access lists or other match conditions to identify traffic
that should be routed through the policy route along with the next-hop router
through which the traffic should be forwarded.
Using
accelerators with PBR allows network administrators to treat the accelerator as
a next-hop router for traffic flows that are candidates for optimization. PBR
can also be used in conjunction with network availability management mechanisms,
such as IP service level agreements (IP SLAs) or Cisco Discovery Protocol (CDP)
neighbor adjacency verification, to track the availability of the accelerator as
a next-hop router. If no accelerators are available, the policy route is
considered invalid because the next-hop router (in this case the accelerator) is
not reachable or available on the network. In such a case, the flow is not
routed through the accelerator and is instead routed using the entries in the
routing table.
Figure 3-24 shows an example of how accelerators can be
deployed as next-hop routers when using PBR.

Server Load Balancing
Server load balancer (SLB) devices, also
known as Layer 4 or Layer 7 switches, can also be used to integrate accelerator
devices into the network. SLB devices can inspect traffic traversing the network
and load-balance flows against one or multiple managed accelerators in a farm.
SLB devices are typically deployed as an appliance but in many cases can be
deployed in an integrated form factor within existing network devices such as
data center switches. SLB devices commonly handle flow management and load
balancing in hardware, which enables the greater levels of scalability and
performance that are required in the enterprise data center.
Many SLB devices offer features beyond server load
balancing, including better server scalability and security. This is
accomplished through security protocol offload (allowing the SLB to manage SSL
termination, encryption and decryption), TCP connection management, application
acceleration functionality (complementary to accelerator functionality), and
application firewall functionality. SLB devices can scale a farm of accelerators
to hundreds of nodes if necessary, supporting multiple gigabits of throughput
and millions of TCP connections.
Figure 3-25 shows an example of an intelligent switch with
integrated server load-balancing capabilities being used as a means of
integrating accelerators transparently into a data center network.
