Configuring asymmetric routing features
You enable asymmetric route detection in the Networking > Networking Integration: Asymmetric Routing page.
Asymmetric route detection automatically detects and reports asymmetric routing conditions and caches this information to avoid losing connectivity between a client and a server.
Asymmetric routing is when a packet takes one path to the destination and takes another path when returning to the source. Asymmetric routing is common within most networks; the larger the network, the more likely there is asymmetric routing in the network.
The asymmetric routing feature is compatible with IPv6.
Asymmetric routing is undesirable for many network devices including, firewalls, VPNs, and RiOS appliances. These devices all rely on seeing every packet to function properly. When RiOS appliances are deployed in a network, all TCP traffic must flow through the same appliances in the forward and reverse directions. If traffic flows through a RiOS appliance in one direction and not the other, then TCP clients are unable to make connections to TCP servers. When deploying RiOS appliances into redundant networks, there is a possibility of traffic taking different forward and return paths so that traffic in one direction goes through RiOS appliances but traffic in the reverse direction does not.
Asymmetric automatic detection enables RiOS appliances to detect the presence of asymmetry within the network. Asymmetry is detected by the client-side appliances. Once detected, the appliance passes through asymmetric traffic unoptimized allowing the TCP connections to continue to work. The first TCP connection for a pair of addresses might be dropped because during the detection process the appliances have no way of knowing that the connection is asymmetric.
If asymmetric routing is detected, an entry is placed in the asymmetric routing table and any subsequent connections from that IP-address pair is passed through unoptimized. Further connections between these hosts are not optimized until that particular asymmetric routing cache entry times out.
The Networking > Network Integration: Asymmetric Routing page displays the asymmetric routing table. This table describes the different types of asymmetry.
Type | Description | Asymmetric routing table and log entries |
Complete Asymmetry | Packets traverse both RiOS appliances going from the client to the server but bypass both appliances on the return path. | • Asymmetric Routing Table: bad RST • Log: Sep 5 11:16:38 gen-sh102 kernel: [intercept.WARN] asymmetric routing between 10.11.111.19 and 10.11.25.23 detected (bad RST) |
Server-Side Asymmetry | Packets traverse both RiOS appliances going from the client to the server but bypass the server-side SteelHead on the return path. | • Asymmetric Routing Table: bad SYN/ACK • Log: Sep 7 16:17:25 gen-sh102 kernel: [intercept.WARN] asymmetric routing between 10.11.25.23:5001 and 10.11.111.19:33261 detected (bad SYN/ACK) |
Client-Side Asymmetry | Packets traverse both RiOS appliances going from the client to the server but bypass the client-side appliance on the return path. | • Asymmetric Routing Table: no SYN/ACK • Log: Sep 7 16:41:45 gen-sh102 kernel: [intercept.WARN] asymmetric routing between 10.11.111.19:33262 and 10.11.25.23:5001 detected (no SYN/ACK) |
multiSYN Retransmit | The types of multi-SYN retransmits are: • Probe-filtered occurs when the client-side appliance sends out multiple SYN+ frames and does not get a response. • SYN-remit occurs when the client-side appliance receives multiple SYN retransmits from a client and does not see a SYN/ACK packet from the destination server. | • Asymmetric Routing Table: probe-filtered (not-AR) • Log: Sep 13 20:59:16 gen-sh102 kernel: [intercept.WARN] it appears as though probes from 10.11.111.19 to 10.11.25.23 are being filtered. Passing through connections between these two hosts. |
Detecting and caching asymmetric routes does not optimize these packets. If you want to optimize asymmetric routed packets, you must make sure that packets going to the WAN always go through a RiOS appliance either by using a multiport SteelHead, connection forwarding, or using external ways to redirect packets, such as WCCP or PBR.
For details, see
Configuring connection forwarding features or the
SteelHead Deployment Guide.
Troubleshooting asymmetric routes
You can use these tools to detect and analyze asymmetric routes:
• TCP Dump - Run a TCP dump diagnostic report on the client-side appliance to verify the packet sequence that is causing the asymmetric route detection. You can take traces on the LAN and WAN ports of the appliance and, based on the packet maps, look for the packet sequence that is expected for the type of warning message that was in the log.
As an example, perform these steps to obtain information about all packets on the WAN interface sourced from or destined to 10.0.0.1, and with a source and destination TCP port of 80:
1. Choose Reports > Diagnostics: TCP Dumps to display the TCP Dumps page.
2. Click Add a New TCP Dump.
3. Select the WAN interface.
4. Specify 10.0.0.1 as the source and destination address.
5. Specify TCP port 80 as the source and destination port.
6. Select the Schedule Dump check box and specify the date and time to initiate the dump.
7. Specify any other options such as the capture filename or duration.
8. Click Add.
• Trace Route - From the CLI, run the traceroute command to discover what path a packet is taking from the client to the server and from the server to the client. You access the client and run the traceroute command with the IP address of the server, and then run the traceroute command from the server with the IP address of the client. For example, for a Cisco router with a client address of 10.1.0.2 and a server address of 10.0.0.4:
client# traceroute 10.0.0.4 Type escape sequence to abort.
Tracing the route to 10.0.0.4
1 10.1.0.1 4 msec 0 msec 4 msec
2 10.0.0.2 4 msec 4 msec 0 msec
3 10.0.0.3 4 msec 4 msec 0 msec
4 10.0.0.4 4 msec 4 msec 0 msec
server# traceroute 10.1.0.2 Type escape sequence to abort.
Tracing the route to 10.1.0.2
1 10.0.0.6 4 msec 0 msec 4 msec
2 10.0.0.5 4 msec 4 msec 0 msec
3 10.1.0.1 4 msec 4 msec 0 msec
4 10.1.0.2 4 msec 4 msec 0 msec
For details, see the Riverbed Command-Line Interface Reference Manual or the SteelHead Deployment Guide.
To automatically detect asymmetric routing
1. Choose Networking > Network Integration: Asymmetric Routing to display the Asymmetric Routing page.
Figure: Asymmetric Routing page
2. Under Asymmetric Routing Settings, complete the configuration as described in this table.
Control | Description |
Enable Asymmetric Routing Detection | Detects asymmetric routes in your network. |
Enable Asymmetric Routing Pass-Through | Enables pass-through traffic if asymmetric routing is detected. If asymmetric routing is detected, the pair of IP addresses, defined by the client and server addresses of this connection, is cached on the SteelHead. Further connections between these hosts are passed through unoptimized until that particular asymmetric routing cache entry times out. Detecting and caching asymmetric routes does not optimize these packets. If you want to optimize asymmetric routed packets you must make sure that the packets going to the WAN always go through a RiOS appliance either by using a multiport SteelHead, connection forwarding, or using external ways to redirect packets, such as WCCP or PBR. For details, see the SteelHead Deployment Guide. |
Remove Selected | Select the check box next to the name and click Remove Selected. |
3. Click Save to save your settings permanently.
Related topics