TFTP is a free, open source IPv6 ready application that includes DHCP, TFTP, DNS, SNTP and Syslog servers as well as a TFTP client.
The Kemp LoadMaster is used to load balance the TFTP Server workload. The LoadMaster offers advanced Layer 4 and Layer 7 server load balancing, SSL Acceleration and a multitude of other advanced Application Delivery Controller (ADC) features. The LoadMaster intelligently and efficiently distributes user traffic among the application servers so that users get the best experience possible.
This document provides the recommended LoadMaster settings used when load balancing the TFTP Server workload. The Kemp Support Team is available to provide solutions for scenarios not explicitly defined. The Kemp support site can be found at:
This document is intended to be read by anyone who is interested in configuring the LoadMaster to optimize the TFTP Server.
The deployed TFTP Server environment determines which of the following setups is used.
It is best practice to enable the Subnet Originating Requests option globally.
In a one-armed setup (where the Virtual Service and Real Servers are on the same network/subnet) Subnet Originating Requests is usually not needed. However, enabling Subnet Originating Requests should not affect the routing in a one-armed setup.
In a two-armed setup where the Virtual Service is on network/subnet A, for example, and the Real Servers are on network B, Subnet Originating Requests should be enabled on LoadMasters with firmware version 7.1-16 and above.
Because this application can run at Layer 4, transparency is enforced. Transparency takes a higher priority than Subnet Originating Requests. Therefore, if transparency is enabled on the Virtual Service and Subnet Originating Requests is enabled globally, the Virtual Service still uses transparency. The Real Server sees traffic from this virtual service originating with the clientâs source IP address (transparency). See the Transparency document on the Kemp documentation page for more details.
In the diagram above, you can see the following details:
- Client: 10.0.0.100/24
- Virtual Service on eth0: 10.0.0.15/24
- Real Server on eth1: 10.20.20.25/24
With Subnet Originating Requests enabled, the Real Server sees traffic originating from 10.20.20.21 (LoadMaster eth1 address) and responds correctly.
With Subnet Originating Requests disabled, the Real Server sees traffic originating from 10.0.0.15 (LoadMaster Virtual Service address on eth0) and responds to eth0 causing asymmetric routing
When Subnet Originating Requests is enabled globally, it is automatically enabled on all Virtual Services. If the Subnet Originating Requests option is disabled globally, you can choose whether or not to enable Subnet Originating Requests on a per-Virtual Service basis.
To enable Subnet Originating Requests globally, follow the steps below:
1. In the main menu of the LoadMaster Web User Interface (WUI), go to System Configuration > Miscellaneous Options > Network Options.
2. Select the Subnet Originating Requests check box.
It is recommended that you change the Always Check Persist option to Yes â Accept Changes. Use the following steps:
1. Go to System Configuration > Miscellaneous Options > L7 Configuration.
2. Click the Always Check Persist drop-down arrow and select Yes â Accept Changes.
The following are the steps involved and the recommended settings to configure the TFTP Virtual Service:
1. In the main menu of the LoadMaster WUI, go to Virtual Services > Add New.
2. Type a valid Virtual Address.
3. Type 69 as the Port.
4. Enter a recognizable Service Name, such as TFTP Virtual Service.
5. Select udp as the Protocol.
6. Click Add this Virtual Service.
7. Configure the settings as shown in the following table:
|Scheduling Method||least connection|
Real Server Check Method
8. Add the Real Servers:
a) Expand the Real Servers section.
b) Click Add New.
c) Enter the address of the relevant Real Server.
d) Complete the other fields as required.
e) Click Add this Real Server then click OK to the pop-up message.
f) Repeat the steps above to add more Real Servers as needed, based on your environment.
This document was last updated on 30 January 2019.