There are two primary ways in which symmetric acceleration devices communicate across a WAN. These are:
- Header transparency: WAN acceleration appliances preserve the original source and destination IP addresses of the clients and servers when sending packets across the WAN. This information is used to route accelerated traffic across the WAN in the same manner as un-accelerated traffic. It is important to point out that while the headers remain unchanged in this scenario, payload information is fundamentally altered as compression, data reduction and other acceleration techniques are applied to the WAN traffic.
- Peering: During transit over the WAN, the original source IP address is replaced with the IP address of the near-end WAN acceleration appliance. The original destination IP address is replaced with the IP address of the far-end acceleration device. Peering is most commonly implemented using Network Address Translation (NAT) or by encapsulation within tunneling protocols, such as GRE.
By using intermediary IP addresses,
- peering establishes well-defined ingress and egress points for all accelerated traffic across the WAN. After acceleration takes place, the intermediary headers are replaced with the originals. As is the case with header transparency, when traffic is optimized and sent across the WAN using peering, payload information is inherently altered.
There are advantages and disadvantages to the different methods of communication across a WAN. Header transparency improves visibility into the header, which can be used to enforce downstream ACLs and QoS policies on simple protocols, such as CIFS. It does not provide visibility into the payload, however, and this limits its value when applications use ephemeral ports (e.g., VoIP, FTP and MAPI). In addition, this method can actually be problematic when downstream devices are using deep-packet inspection to compare header information with payload information, and can be costly to deploy and complicated to manage in networks with multiple WAN paths.
A clear vision for transparency
Both methods described above are effective ways of communicating across a WAN, but neither method -- by itself -- delivers the level of transparency required to preserve all existing policies across a WAN. Any claims to the contrary are deliberately misleading. For a WAN acceleration solution to be truly transparent it must:
- Work across all applications, not just those using a specific type of port or transport protocol.
- Co-exist with other devices in the network, such as IDS/IPS and firewalls.
- Be completely seamless to the client, server and application itself without any risk of data corruption.
To achieve end-to-end transparency, vendors have to augment one of the above communication methods with other techniques. For example, the following can be used in conjunction with peering to provide end-to-end visibility across the WAN:
- Deep-packet inspection delivers detailed visibility into all traffic, including those applications that use ephemeral ports. Best practice indicates that deep inspection and related functions take place prior to WAN optimization or within the optimization appliance itself. Otherwise, WAN optimization techniques that obscure payload information may render devices that use deep-packet inspection useless.
- "Auto-optimization" enables the first few packets in a flow to be sent across the WAN in the clear so that existing policies can be enforced appropriately prior to optimization. For example, if an ACL exists within the WAN to deny a specific type of traffic, acceleration appliances will not optimize this traffic and the ACL will continue to function as if the appliance were not there. This process is similar to the one used by Layer 3 switches, whereby for each new flow, the first few packets are processed by an embedded router and then copied for the remaining packets (hardware fast path).
- DSCP tags can be used to preserve QoS policies within the WAN acceleration appliance. These devices can also overwrite DSCP tags based on configurable QoS policies.
- Netflow is often used to collect network-flow-based statistics and traffic accounting information on all traffic, which can be exported to external devices in a well-defined format that is easily recognized. This enables a variety of key tasks, such as network traffic accounting, usage-based network billing, network planning, security, Denial of Service (DoS) protection, and network monitoring.
About the author:
Dr. David Hughes founded Silver Peak Systems in 2004 and previously held senior architect positions with Cisco Systems, Stratacom, Blueleaf and Nortel. He has a PhD in packet network optimization.
This was first published in January 2007