This section describes port transparency and full address transparency. This section includes the following topics:

Transparent addressing reuses client and server addressing for optimized traffic across the WAN. Traffic is optimized, although addressing appears to be unchanged. Both optimized and pass-through traffic present identical addressing information to the router and network monitoring devices.

In RiOS v5.0.x or later, transparent addressing can be used in conjunction with many deployment configurations and features, including, but not limited to:

Transparent addressing does not support the following deployment configurations:

You configure transparent addressing on the client-side SteelHead (where the connection is initiated). Both the server-side and the client-side SteelHeads must support transparent addressing (RiOS v5.0.x or later) for transparent addressing to work. You can configure a SteelHead for transparent addressing even if its peer does not support it. The connection is optimized, but it is not transparent.

When you use full or port transparency, SteelHeads add a TCP option field to the packet headers of optimized traffic. This TCP option field is sent between the SteelHeads. For transparency to work, this option must not be stripped off by intermediate network devices.

A given pair of SteelHeads can also have multiple types of transparent addressing enabled for different connections. For example, a pair of SteelHeads can use correct addressing for connections to a destination subnet, and use full address transparency or port transparency for connections to another destination subnet. A pair of SteelHeads can also use correct addressing for connections to a destination port, and use full address transparency or port transparency for connections to another destination subnet.

If both port transparency and full address transparency are acceptable solutions, port transparency is preferable. Port transparency avoids potential networking risks that are inherent in enabling full address transparency.

For details, see Implications of Transparent Addressing.

Port transparency preserves your server port numbers in the TCP/IP header fields for optimized traffic in both directions across the WAN. Traffic is optimized even though the server port number in the TCP/IP header field appears to be unchanged. Routers and network monitoring devices deployed in the WAN segment between the communicating SteelHeads can view these preserved fields.

Port transparency does not require dedicated port configurations on your SteelHeads.

Port transparency provides server only port visibility. Port transparency does not provide client and server IP address visibility, nor does it provide client port visibility.

Figure 3‑2 shows TCP/IP packet headers when port transparency is enabled. Server port numbers are visible across your WAN.

To compare port transparency packet headers to correct addressing packet headers, see Figure 3‑1.

Port transparency uses the following values in your TCP/IP packet headers in both directions:

Use port transparency if you want to manage and enforce QoS policies that are based on destination ports. If your WAN router is following traffic classification rules that are written in terms of TCP destination port numbers, port transparency enables your routers to use existing rules to classify the traffic without any changes.

Port transparency enables network analyzers deployed within the WAN (between the SteelHeads) to monitor network activity, and to capture statistics for reporting, by inspecting traffic according to its original TCP destination port number.

For information about configuring port transparency, see Configuring WAN Visibility Modes.

This section describes full address transparency. This section includes the following topics:

Full address transparency preserves your client and server IP addresses and port numbers in the TCP/IP header fields for optimized traffic in both directions across the WAN. VLAN tags can also be preserved. Traffic is optimized even though these TCP/IP header fields appear to be unchanged. Routers and network monitoring devices deployed in the WAN segment between the communicating SteelHeads can view these preserved fields.

Figure 3‑3 shows how TCP/IP packet headers might be addressed when full address transparency is enabled. In this example, SteelHead IP addresses and port numbers are no longer visible on the optimized connections. Client and server IP addresses and port numbers are now visible in both directions across the WAN.

When you enable full address transparency, you have several addressing options for the out-of-band (OOB) connection. The type of addressing you configure for your OOB connection ultimately determines whether the SteelHead in-path IP addresses are used in the TCP/IP packet headers.

For information about OOB, see The Out-of-Band Connection.

To compare full address transparency packet headers with correct addressing packet headers, see Figure 3‑1.

In this example, full address transparency uses the following values in the TCP/IP packet headers in both directions:

For information about configuring full address transparency, see Configuring WAN Visibility Modes.

If both port transparency and full address transparency are acceptable solutions, port transparency is preferable. Port transparency mitigates potential networking risks that are inherent in enabling full address transparency.

For details, see Implications of Transparent Addressing.

However, if you must use your client or server IP addresses across your WAN, full address transparency is your only configuration option. Full address transparency enables network monitoring applications deployed within the WAN (between the SteelHeads) to measure traffic sent to the WAN by the end-host. Network routers can also perform load-balancing and policy-based routing. Full address transparency also enables you to manage and enforce QoS policies based on port numbers or IP addresses.

Full address transparency also enables the use of Network Address Translation (NAT). With correct addressing, SteelHeads use their own IP addresses in the packet header, which NAT does not recognize. When full address transparency is enabled, the original client and server IP addresses are used, and the connections are recognizable to NAT. However, the type of addressing you configure for your out-of-band (OOB) connection ultimately determines whether the SteelHead in-path IP addresses are used in the TCP/IP packet headers.

Full address transparency also supports several transparency options for the OOB connection.

For information about OOB, see The Out-of-Band Connection.

Full address transparency supports transparent VLANs. You can configure full address transparency so that optimized traffic remains on the original VLANs. Because you can keep traffic on the original VLANs, full address transparency enables you to perform VLAN-based QoS on the WAN side of the SteelHead.

If packets on your network use two different VLANs in the forward and reverse directions, see the Riverbed Knowledge Base article, Understanding VLANs and Transparency, located at https://supportkb.riverbed.com/support/index?page=content&id=S15176.

The Full Address Transparency with Forward Reset mode is similar to the Full Address Transparency WAN visibility mode. Like Full Address Transparency, use this mode to preserve the client and server IP addresses and TCP ports used for the WAN-side TCP connections between SteelHeads. The difference between the two modes happens during the auto-discovery phase, during which TCP reset packets are transmitted on the WAN. These packets help network devices like stateful firewalls separate TCP state between the SteelHeads discovery phase and the data transmission phase.

Except for the TCP reset packets during the discovery phase, there are no other differences between Full Address Transparency and Full Address Transparency with Forward Reset, including the addressing of the WAN-side TCP connection, considerations for 802.1Q VLAN tracking, and OOB transparency.

Figure 3‑4 shows the auto-discovery packet flow when using the Full Transparency with Forward Reset mode and enhanced auto-discovery. The packet marked Forward Reset is the only difference between this mode and the Full Transparency mode.

In Full Address Transparency with Forward Reset mode, TCP reset packets are transmitted by the initiating SteelHead immediately after the remote SteelHead is discovered. The reset packets traverse the WAN and are absorbed by the remote SteelHead. The packets aid any TCP-aware device on the WAN to understand that the sequence numbers used during the auto-discovery phase is different from the sequence numbers used during the data transmission phase. Example devices include: