Download Report

Technology Primer: TCP Connection Forwarding
Blue Coat ProxySG appliances utilizing MACH5 WAN Optimization allow IT organizations to accelerate and
secure the delivery of business applications for all users across the distributed enterprise - including those
near Internet gateways, as well as in branch offices, data centers, and even individual end points. As part
of the MACH5 WAN Optimization solution, ProxySG appliances can perform TCP Connection Forwarding,
which enables them to make intelligent decisions regarding the handling of TCP connections across groups
of appliances.
What is TCP Connection Forwarding?
TCP Connection Forwarding is a Blue Coat feature that enables ProxySG appliances to share TCP connection information
and selectively forward TCP connections to other ProxySG appliances. Through sharing TCP connection information,
intercepted connections can be routed to other ProxySG appliances in the network for the purpose of either load balancing
transparent ADN connections across clusters, or routing application connections that would have previously failed due to
network routing decisions.
Why should I perform TCP Connection Forwarding in my network?
TCP Connection Forwarding is designed to address common deployment scenarios:
--> Transparent deployments where asymmetric routing conditions exist. An asymmetric route is where the path from
client to server is different than the return path from server to client. Some examples of where this can occur are
with external load balancing or failover.
--> Transparent ADN deployments where multiple ProxySG appliances are used for load balancing or high availability.
In the case where there are asymmetric routing conditions, enabling TCP Connection Forwarding is a simple solution to
resolve a complex network routing problem. Using TCP Connection Forwarding to track connections, administrators do not
need to rely on configuring switches and/or routers to ensure that connections are routed to the correct appliance.
For networks where the WAN Optimization solution requires load balancing or failover, TCP Connection Forwarding provides
a mechanism for ensuring ADN connections coming from across the WAN are forwarded to the appropriate appliance in the
cluster. This minimizes the duplication of data across appliances in the cluster, and the load balancing functionality eliminates
the need for an external load balancing device.
How does TCP Connection Forwarding work?
TCP Connection Forwarding requires a cluster of two or more ProxySG appliances configured as peers. To create a TCP
Connection Forwarding peer cluster, each peer in the cluster must be configured with the IP address of all other peers in
the cluster. This enables all of the peers to share TCP connection information, allowing them to identify which connections
exist on which peer. When TCP Connection Forwarding is enabled, each peer can intelligently process the connections that
Technology Primer: TCP Connection Forwarding
it intercepts. Each connection received by a peer will either be processed, or forwarded to another peer in the cluster using
IP-in-IP encapsulation (similar to Generic Route Encapsulation). TCP Connection Forwarding is designed for networks with low
latency, high bandwidth, and virtually no packet loss. Exactly how TCP Connection Forwarding works given specific deployment
scenarios is explained below:
Transparent Deployments and Asymmetric Routing
When multiple appliances are deployed on a LAN, external load balancing devices are often used to distribute network traffic in
a way that maximizes resources and minimizes points of failure. Good network design often includes redundant hardware and
data paths to ensure high availability, creating multiple paths from one network node to another so that no single failure along
the way blocks communication between them. If achieving this in the network includes load balancing network traffic between
routers, or if your network relies on Internet connectivity from multiple ISPs, asymmetric routing can occur. With asymmetric
routing, individual packets in a single connection might travel different paths to (or from) their destination. Normally this would
not create a problem, but if transparency is required on either the client or server-side, this situation can be troublesome for
an appliance that depends on seeing all data for a given transaction.
Transparent deployment of a ProxySG appliance means that from the perspective of the client or server, the ProxySG appliance
is not visible. Requests originating from the ProxySG appliance appear as if they originated from the client, and responses
originating from the ProxySG appliance appear as if they originated from the server. With client-side transparency, load
sharing devices might incorrectly send subsequent traffic already associated with one ProxySG appliance to a different
ProxySG appliance. The load sharing device has no way of identifying which ProxySG appliance was associated with the
traffic flow. Upon receiving a packet that is part of a connection that it does not own, the ProxySG appliance attempts to reset
the connection, resulting in the end user receiving either an error page or connection timeout. Similarly, with server-side
transparency, also called ip spoofing, routers have no way of knowing which ProxySG appliance initiated the connection
because the source IP address of packets originating from the ProxySG appliance to the server actually have the source IP
address of the client (and not the appliance). As a result, server return traffic may be sent to a different ProxySG appliance
than the one from which the transaction was originally initiated.
To solve the problem of connections being routed to the wrong appliance, ProxySG appliances use TCP Connection Forwarding.
As connections are initiated by clients to the ProxySG appliance, and initiated by the ProxySG appliance to servers, the
ProxySG appliance shares information about the connections it owns with other peers in the cluster. Each peer in the cluster
participates, enabling each one to identify which peer a particular connection belongs to. If a peer in the cluster receives
packets that are part of a connection existing on another peer in the cluster, it forwards it to that peer, eliminating the routing
problem caused by asymmetric routing. The diagrams below detail two of the most common scenarios:
Technology Primer: TCP Connection Forwarding
Asymmetric Routing as a Result of Load Balancing
In the diagram above, the ACK is sent to BC2. BC2 did not receive the initial SYN
and has no knowledge of the connection. This results in a failed connection.
With TCP Connection Forwarding, BC2 knows that BC1 owns the
connection associated with the ACK and forwards it to BC1.
Asymmetric Routing as a Result of Multiple Service Providers
In the diagram above, the SYN ACK from the server enters the
network through a different service provider and is routed to the
wrong ProxySG appliance.
With TCP Connection Forwarding, BC2 knows that BC1 owns the
connection associated with the SYN ACK and forwards it to BC1.
Technology Primer: TCP Connection Forwarding
Load Balancing Incoming Transparent ADN Connections Across a Cluster
ProxySG appliances have the ability to load balance transparent ADN connections across a cluster of appliances. By putting
one or more ProxySG appliances inline to intercept all of the network traffic on that segment, connections can be load
balanced to any number of ProxySG appliances using TCP Connection Forwarding. As the inline appliance intercepts traffic
coming in from the WAN, it load balances the connections to any number of configured peers using the load sharing/failover
mechanisms built into the ADN protocol. The inline device can be configured to intercept connections, intercept only some
connections, or forward all of them. A backup inline device can be configured using SGRP.
In the diagram above, both inline appliances BC1 and BC2 function as load balancers, distributing incoming ADN connections between BC3, BC4, and BC5. With ip
spoofing enabled, connections originating from the servers will always be routed through the inline devices, which will then forward them to the correct appliance.
Blue Coat Difference
Scalable ADN Load Balancing Across Clusters
Blue Coat TCP Connection Forwarding provides a highly flexible, scalable mechanism for managing ADN connections
across clusters, without the requirement of an external load balancing device. This feature is available on all Blue Coat
ProxySG platforms and can be configured to load balance only, or share some of the traffic processing in conjunction with load
balancing.
IP-in-IP Tunneling
TCP Connection Forwarding uses IP-in-IP tunneling to encapsulate data between appliances. This is an advantage because IPin-IP is well known (based on RFC 1853) and the cluster of peers is not restricted to a multicast domain.
Ease of Deployment
Layer 4 transparent deployments can often present routing challenges depending on network topology. With TCP Connection
Forwarding, proper traffic management is possible without relying on complex router configurations to do packet redirection.
Blue Coat Systems, Inc. 1.866.30.BCOAT // 408.220.2200 Direct // 408.220.2250 Fax // www.bluecoat.com
Copyright © 2007 Blue Coat Systems, Inc. All rights reserved worldwide. No part of this document may be reproduced by
any means nor translated to any electronic medium without the written consent of Blue Coat Systems, Inc. Specifications
are subject to change without notice. Information contained in this document is believed to be accurate and reliable,
however, Blue Coat Systems, Inc. assumes no responsibility for its use, Blue Coat is a registered trademark
of Blue Coat Systems, Inc. in the U.S. and worldwide. All other trademarks mentioned in this document are
the property of their respective owners. v.TP-TCPCNCTFRWD-v3-1207