---
title: Asymmetric Routing Issues
description: "## Overview This article explains how to identify and resolve **asymmetric routing issues** in a RELIANOID deployment when the load balancer has multiple network interfaces connected to different subnets. This situation can occur when frontend clients need to access backend…"
url: "https://www.relianoid.com/resources/knowledge-base/troubleshooting/asymmetric-routing-issues/"
updated: "2026-03-12"
category: Troubleshooting
---

# Asymmetric Routing Issues

## Overview

This article explains how to identify and resolve **asymmetric routing issues** in a RELIANOID deployment when the load balancer has multiple network interfaces connected to different subnets.

This situation can occur when frontend clients need to access backend services located in another subnet while the load balancer has interfaces in both networks.

![relianoid_asimetric_routing](https://static.relianoid.com/wp-content/uploads/2026/03/Asymmetric-routing.svg)

Improper routing behavior may cause response traffic to exit through a different interface than the one used for the incoming request, resulting in **asymmetric routing**.

# Problem Description

In some deployments, the RELIANOID load balancer is configured with multiple interfaces connected to different networks.

The following configuration is an **example environment used for demonstration purposes**.

| Interface | Network | Purpose |
| --- | --- | --- |
| eth0 | 192.168.1.0/24 | Management |
| eth1 | 192.168.110.0/24 | Frontend |
| eth2 | 192.168.100.0/24 | Application / Backend |

Backend servers are located in the **192.168.100.0/24** subnet and are accessed through farms configured on the load balancer.

However, some clients located in the **192.168.110.0/24** network also need to access services hosted in the **192.168.100.0/24** network.

Because the load balancer has an interface in both networks and the IP Forwarding is active by default, the system may route response traffic directly through the **frontend interface (eth1)** instead of routing it through the expected gateway.

This results in **asymmetric routing**, which may cause connection failures or dropped packets.

### Example Interface Configuration

![relianoid_example_interface_configuration](https://static.relianoid.com/wp-content/uploads/2026/03/relianoid_example_interface_configuration.png)

## What is Asymmetric Routing

Asymmetric routing occurs when the **incoming and outgoing traffic of the same connection follow different network paths**.

### Example Flow

**Destination Path:**192.168.110.11 via eth2 (Client) > 192.168.100.100 (Load Balancer) > 192.168.100.42 (Backend)

**Return Path (Incorrect):**192.168.100.42 (Backend) > 192.168.100.100 (Load Balancer) > 192.168.110.11 via eth1 (Client)

Because the return traffic leaves through a different interface, intermediate devices such as firewalls or routers may drop the packets.

# How Routing Tables Work

RELIANOID uses **per-interface routing tables** to control how traffic is forwarded between networks.

Each interface automatically generates its own routing table.

Example routing tables: `table_eth1`, `table_eth2`

These routing tables define:

- Routes associated with the interface
- Gateways used for traffic forwarding
- Interfaces that are allowed to route traffic

Within each routing table, interfaces can be configured as:

### Managed Interfaces

Interfaces that are allowed to route traffic within the routing table making use of the IP Forwarding feature.

### Unmanaged Interfaces

Interfaces that are excluded from routing decisions for that table and the IP Forwarding won’t apply for those interfaces.

By controlling which interfaces are managed or unmanaged, administrators can influence how traffic flows through the load balancer and prevent routing conflicts.

### Example Routing Table

![relianoid_example_routing_table](https://static.relianoid.com/wp-content/uploads/2026/03/relianoid_example_routing_table.png)

# Solution

To resolve the asymmetric routing issue, the conflicting interface must be excluded from the routing table associated with the backend network.

In this scenario, **eth1 should be removed from the routing table**`table_eth2`, ensuring traffic is routed through the correct gateway.

![relianoid_simetric_routing](https://static.relianoid.com/wp-content/uploads/2026/03/Symmetric-routing.svg)

# Solution Using the Web UI

1. Navigate to: Network > Routing
2. Select the routing table associated with the backend interface: `table_eth2`
3. Scroll to the bottom of the page.
4. Locate the **Managed Interfaces** section.
5. Move the interface **eth1** from **Managed Interfaces** to **Unmanaged Interfaces**.

This prevents traffic from being routed directly through the frontend interface when the backend routing table is used.
 ![solution_using_webgui](https://static.relianoid.com/wp-content/uploads/2026/03/solution_using_webgui.png)

# Solution Using CLI

The same configuration can also be applied using the RELIANOID CLI.

### Step 1: Enable API Access

Navigate to: System > User Settings

Enable API Access and configure an API key. You can either define your own key or generate a random one.

After creating the key, copy and save it, as it will be required the first time you access the CLI using noid-cli

### Step 2: Access RELIANOID CLI

From the system console, run:

```
noid-cli
```

Enter the API key when prompted.

### Step 3: Remove Interface From Routing Table

Execute the following command:

```
network-routing-table-unmanaged add table_eth2 -interface eth1
```

This command prevents traffic from being routed through **eth1** when using routing table `table_eth2`.

### Step 4: Revert the Configuration (Optional)

If needed, the configuration can be reverted with the following command:

```
network-routing-table-unmanaged remove table_eth2 eth1
```

# Best Practices

- Perform routing changes during **low traffic hours or maintenance windows**.
- Validate connectivity after applying the configuration.
- Ensure that other services are not affected by routing changes.

# Conclusion

Asymmetric routing issues may occur when a load balancer is connected to multiple networks and traffic returns through a different interface than the one used for the incoming connection.

In RELIANOID, this issue can be resolved by adjusting routing table configurations and excluding conflicting interfaces from specific routing tables.

This ensures that traffic follows the correct network path and prevents connectivity problems.

### 📄 Download this document in PDF format