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’s asymmetric routing in the network.
The asymmetric routing feature in RiOS 8.5 and later is compatible with IPv6.
Asymmetric routing is undesirable for many network devices, including firewalls, VPNs, and SteelHeads. These devices all rely on seeing every packet to function properly. When SteelHeads are deployed in a network, all TCP traffic must flow through the same SteelHeads in the forward and reverse directions. If traffic flows through a SteelHead in one direction and not the other, then TCP clients are unable to make connections to TCP servers. When deploying SteelHeads into redundant networks, there’s a possibility of traffic taking different forward and return paths so that traffic in one direction goes through SteelHeads but traffic in the reverse direction doesn’t.
Asymmetric automatic detection enables SteelHeads to detect the presence of asymmetry within the network. Asymmetry is detected by the client-side SteelHeads. Once detected, the SteelHead 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 SteelHeads 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 aren’t 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 SteelHeads going from the client to the server but bypass both SteelHeads 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 SteelHeads 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 SteelHeads going from the client to the server but bypass the client-side SteelHead 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 SteelHead sends out multiple SYN+ frames and doesn’t get a response. • SYN-remit occurs when the client-side SteelHead receives multiple SYN retransmits from a client and doesn’t 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 doesn’t 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 SteelHead 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 SteelHead to verify the packet sequence that is causing the asymmetric route detection. You can take traces on the LAN and WAN ports of the SteelHead 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, 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 tool 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, then run the traceroute command from the server with the IP address of the client: for example, for a Cisco router:
#Client’s Address: 10.1.0.2
#Server’s Address: 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 doesn’t 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 SteelHead 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 Disk to save your settings permanently.
Related Topics