About Packet Mode Acceleration
Packet mode acceleration enables the SteelHead to perform packet-by-packet acceleration on various types of IPv4 and IPv6 traffic.
The packet mode acceleration feature can optimize TCP IPv6 and UDP IPv4 traffic. When you use packet mode acceleration, the SteelHead applies the same SDR and LZ data streamlining techniques to UDP or TCP IPv6 packets. Packet mode acceleration achieves data reduction rates similar to TCP IPv4 traffic.
About TCP proxy mode acceleration
The bulk of most network traffic is TCP IPv4 traffic, which SteelHeads typically accelerate using a TCP proxy architecture. TCP proxy mode acceleration separates a TCP connection into three individual connections:
• Client to client-side SteelHead
• SteelHead to SteelHead
• Server-side SteelHead to server
The advantage of TCP proxy mode is that it increases performance. Because the SteelHead acts as a local proxy to the host, the SteelHead is able perform transport streamlining and application streamlining, which results in increased user performance.
However, sometimes you might want to use the SteelHead acceleration to reduce the amount of traffic traversing the WAN. Packet mode acceleration provides a simple approach in which the SteelHead looks at a packet, or small group of packets, and performs SDR and LZ on the data payload for data reduction. The host and SteelHead do not create an individual TCP handshake, and the SteelHead reduces payload for packets as the traffic flows through.
The advantage of packet mode acceleration is that it is a universal method that applies data streamlining to diverse protocols. The disadvantage is the lack of performance benefits from transport streamlining or application streamlining, because the SteelHead does not proxy or perform intelligent application prediction.
Packet mode acceleration is unidirectional—from sender to receiver—which is an effect of not acting as a proxy. For example, take two sites with SteelHeads, Site A and Site B. A device at Site A sends SNMP traps over UDP to a server at Site B, and only SteelHead A is configured to accelerate UDP traffic to SteelHead B. If the server at Site B, for some reason, responds over UDP to the device at Site A, this traffic is not accelerated unless you have configured SteelHead B to accelerate UDP traffic to SteelHead A.
Configuring packet mode acceleration
This section describes how to configure packet mode acceleration for UDP IPv4 and TCP IPv6 traffic.
Packet mode acceleration supports only correct addressing. Packet mode acceleration does not support autodiscovery and requires that you configure fixed-target, packet-mode, in-path rules.
To configure packet mode acceleration for IPv4 traffic
1. From the Management Console, choose Optimization > Network Services: General Service Settings and select Enable Packet Mode Optimization; otherwise, use the packet-mode enable command.
2. Configure a fixed-target (packet mode acceleration) in-path rule on the initiating SteelHead.
To accelerate traffic in both directions, you must configure a similar in-path rule on the peer SteelHead.
Field | Option | Description |
Type | Fixed Target (Packet Mode Optimization) | Specifies the rule type for performing packet mode acceleration. |
Source Subnet | All-IPv4 | Selects all IPv4 addresses. You can choose specific IP addresses or ranges. |
Destination Subnet | All-IPv4 | Selects all IPv4 addresses. You can choose specific IP addresses or ranges. |
Protocol | UDP | Selects acceleration of TCP, UDP, or any type of traffic. |
Target Appliance IP Address | 10.32.9.211 | Specifies the remote SteelHead to accelerate to. You must specify a target with a fixed-target rule. You can also specify a backup appliance. A backup SteelHead is not specified in this example. |
Data Reduction Policy | Normal | Specifies SDR, LZ, or both for data reduction. Normal usage includes both. |
Position | End | Determines which position the rule is in the rule list. You can decide this based on your environment. |
3. Click Add.
To accelerate IPv6 traffic, you must enable packet mode optimization and create a fixed-target packet-mode rule similar to IPv4 traffic, but you must enable IPv6 (IPv6 is enabled by default) and configure an IPv6 setting on the SteelHead in-path interfaces.
To configure packet mode optimization for IPv6 traffic
1. From the Management Console, choose Optimization > Network Services: General Service Settings, otherwise use the packet-mode enable command.
2. Configure a fixed-target (packet mode optimization) in-path rule on the initiating SteelHead.
To accelerate TCP traffic in both directions, you must configure a similar in-path rule on the peer SteelHead.
Field | Option | Description |
Type | Fixed-target (packet mode optimization) | Specifies the rule type for performing packet mode acceleration. |
Source Subnet | All-IPv6 | Selects all IPv6 addresses. You can choose specific IP addresses or ranges. |
Destination Subnet | All-IPv6 | Selects all IPv6 addresses. You can choose specific IP addresses or ranges. |
Protocol | TCP | Selects acceleration of TCP, UDP, or any type of traffic. |
Target Appliance IP Address | 10.32.9.211 | Specifies the remote SteelHead to accelerate to. You must specify a target with a fixed-target rule. You can also specify a backup appliance. A backup SteelHead is not specified in this example. |
Data Reduction Policy | Normal | Specifies SDR, LZ, or both for data reduction. Normal usage includes both. |
Position | End | Determines which position the rule is in the rule list. You can decide this based on your environment. |
3. Click Add.
4. Connect to the Riverbed CLI. You can also use the Management Console.
5. Enable IPv6.
IPv6 is enabled by default.
6. Configure an IPv6 address on a SteelHead in-path interface: interface inpathX_Y ipv6 address <address> <mask-length>.
7. Add IPv6 routes: ipv6 in-path route inpathX_Y <prefix> <prefix-length> <nexthop-v6-address>.
For example, ipv6 in-path route inpath0_0 0::0/0 ba5e:ba11:bab3:f005:ba11:bab3:dead:bea7 sets a default IPv6 gateway.
Design considerations
Packet mode acceleration does not support several network integration features available with TCP proxy acceleration. The following limitations apply to packet-mode accelerated traffic.
Packet mode acceleration supports:
• only fixed-target (packet mode acceleration). autodiscovery is not supported.
• only correct addressing. Full transparency and port transparency are not supported. Because full transparency is not supported, VLAN transparency is also not supported.
• physically and virtually in-path deployments. The exception is WCCP for IPv6 traffic, because the SteelHead WCCPv2 implementation currently does not support IPv6.
• data reduction for all IPv4 and IPv6 traffic.
• connection reporting of packet-mode accelerated traffic flows.
Packet mode acceleration does not support:
• RSP data flow rules.
• NetFlow export of the packet-mode accelerated traffic.
• connection forwarding. This limitation does not imply that parallel SteelHead deployments do not work. As each flow is accelerated unidirectionally, asymmetry does not have the same relevance on packet-mode accelerated traffic.
• SteelHead Interceptor deployments.
• server-side out-of-path configuration.
• QoS shaping, enforcement, or marking. All packet-mode accelerated traffic matches the default QoS default rule and class. The exception is UDP IPv4 traffic, which you can place into an MX-TCP class.
Best practices for packet mode acceleration
We recommend that you use the following best practice guidelines when using packet mode acceleration:
• Target specific applications and servers for packet mode acceleration - Similar to the considerations when performing acceleration on TCP IPv4 traffic, certain traffic types do not lend themselves well to data reduction. For example, encrypted or compressed traffic does not receive significant data reduction. We recommend that you use rules targeting specific networks or ports instead of using broad All-IP targets. Traffic types such as TFTP or UDP-based replication traffic are example target applications.
• Do not accelerate voice or video bearer traffic - While VoIP is one of the more pervasive applications over UDP, VoIP and video RTP traffic are already compressed using specialized codecs. If you attempt to perform further data reduction with SDR or LZ, it is ineffective and can add latency resulting in jitter.
• Use TCP proxy mode acceleration - For application latency improvements for TCP IPv4 or IPv6 traffic, you can use the typical TCP proxy mode acceleration. RiOS includes TCP proxy mode acceleration for IPv6 traffic.