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.

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 #

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 #

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.

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 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.