Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




Red Hat Enterprise Linux 9 Essentials Book now available.

Purchase a copy of Red Hat Enterprise Linux 9 (RHEL 9) Essentials

Red Hat Enterprise Linux 9 Essentials Print and eBook (PDF) editions contain 34 chapters and 298 pages

Preview Book

3.2. Load Balancer Add-On via Direct Routing

As mentioned in Section 1.4.2, “Direct Routing”, direct routing allows real servers to process and route packets directly to a requesting user rather than passing outgoing packets through the LVS router. Direct routing requires that the real servers be physically connected to a network segment with the LVS router and be able to process and direct outgoing packets as well.
Network Layout
In a direct routing Load Balancer Add-On setup, the LVS router needs to receive incoming requests and route them to the proper real server for processing. The real servers then need to directly route the response to the client. So, for example, if the client is on the Internet, and sends the packet through the LVS router to a real server, the real server must be able to go directly to the client via the Internet. This can be done by configuring a gateway for the real server to pass packets to the Internet. Each real server in the server pool can have its own separate gateway (and each gateway with its own connection to the Internet), allowing for maximum throughput and scalability. For typical Load Balancer Add-On setups, however, the real servers can communicate through one gateway (and therefore one network connection).


It is not recommended to use the LVS router as a gateway for the real servers, as that adds unneeded setup complexity as well as network load on the LVS router, which reintroduces the network bottleneck that exists in NAT routing.
The hardware requirements of an Load Balancer Add-On system using direct routing is similar to other Load Balancer Add-On topologies. While the LVS router needs to be running Red Hat Enterprise Linux to process the incoming requests and perform load-balancing for the real servers, the real servers do not need to be Linux machines to function correctly. The LVS routers need one or two NICs each (depending on if there is a back-up router). You can use two NICs for ease of configuration and to distinctly separate traffic — incoming requests are handled by one NIC and routed packets to real servers on the other.
Since the real servers bypass the LVS router and send outgoing packets directly to a client, a gateway to the Internet is required. For maximum performance and availability, each real server can be connected to its own separate gateway which has its own dedicated connection to the carrier network to which the client is connected (such as the Internet or an intranet).
There is some configuration outside of Piranha Configuration Tool that needs to be done, especially for administrators facing ARP issues when using Load Balancer Add-On via direct routing. Refer to Section 3.2.1, “Direct Routing and arptables_jf or Section 3.2.2, “Direct Routing and iptables for more information.

3.2.1. Direct Routing and arptables_jf

In order to configure direct routing using arptables_jf, each real server must have their virtual IP address configured, so they can directly route packets. ARP requests for the VIP are ignored entirely by the real servers, and any ARP packets that might otherwise be sent containing the VIPs are mangled to contain the real server's IP instead of the VIPs.
Using the arptables_jf method, applications may bind to each individual VIP or port that the real server is servicing. For example, the arptables_jf method allows multiple instances of Apache HTTP Server to be running bound explicitly to different VIPs on the system. There are also significant performance advantages to using arptables_jf over the iptables option.
However, using the arptables_jf method, VIPs can not be configured to start on boot using standard Red Hat Enterprise Linux system configuration tools.
To configure each real server to ignore ARP requests for each virtual IP addresses, perform the following steps:
  1. Create the ARP table entries for each virtual IP address on each real server (the real_ip is the IP the director uses to communicate with the real server; often this is the IP bound to eth0):
    arptables -A IN -d <virtual_ip> -j DROP
    arptables -A OUT -s <virtual_ip> -j mangle --mangle-ip-s <real_ip>
    This will cause the real servers to ignore all ARP requests for the virtual IP addresses, and change any outgoing ARP responses which might otherwise contain the virtual IP so that they contain the real IP of the server instead. The only node that should respond to ARP requests for any of the VIPs is the current active LVS node.
  2. Once this has been completed on each real server, save the ARP table entries by typing the following commands on each real server:
    service arptables_jf save
    chkconfig --level 2345 arptables_jf on
    The chkconfig command will cause the system to reload the arptables configuration on bootup — before the network is started.
  3. Configure the virtual IP address on all real servers using ifconfig to create an IP alias. For example:
    # ifconfig eth0:1 netmask broadcast up
    Or using the iproute2 utility ip, for example:
    # ip addr add dev eth0
    As previously noted, the virtual IP addresses can not be configured to start on boot using the Red Hat system configuration tools. One way to work around this issue is to place these commands in /etc/rc.d/rc.local.
  4. Configure Piranha for Direct Routing. Refer to Chapter 4, Configuring the Load Balancer Add-On with Piranha Configuration Tool for more information.

  Published under the terms of the Creative Commons License Design by Interspire