Configuring asymmetric routing features
You enable asymmetric route detection under Networking > Networking Integration: Asymmetric Routing.
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.