LSLB | Farms | Update | L4xNAT Profile

L4xNAT settings configuration

Global Settings.

The L4xNAT farm profile allows to create an LSLB farm at layer 4 with very high performance and much more concurrent connections than load balancer cores in layer 7 like HTTP farm profile. That layer 4 performance improvement counteracts the advanced content handling that the layer 7 farm profile could manage.

Additionally, L4xNAT farm profile could bind a range of ports, not only one virtual port as is used with another layer 7 farm profile. In order to be able to select a range of virtual ports or a specific virtual port in L4xNAT farm profile, it’s mandatory to select a protocol type. In other cases, the farm will be listening on all ports from the virtual IP ( set with a character ‘*‘ ). Once a TCP or UDP protocol is selected, it will be available to specify a port, several ports between ‘,‘, ports range between ‘:‘ or all ports with ‘*‘. A combination of all of them will be valid as well.

The specific options to be able to configure an L4xNAT farm profile is detailed in the current section. It is recommended to use Farm Guardian with this profile because there is not default health check to the backends in this profile.

In this section, the following fields are shown:

Name. It’s the identification field and a description of the farm service. In order to change this value, you’ve to stop the farm in first place. Ensure that the new farm name isn’t already in use or an error message will appear.

Virtual IP and Port. These are the virtual IP address and/or virtual PORT in which the farm will be bound and listening in the load balancer system. To make changes in these fields, ensure that the new virtual IP and virtual PORT are not in use. In order to apply the changes, the farm service will be restarted automatically.

Protocol Type. This field specifies the protocol to be balanced at layer 4. By default, the farm will be available for all layer 4 protocols.

  • ALL. The farm will be listening for incoming connections to the current virtual IP and port(s) overall protocols.
  • TCP. Enabling this option, the farm will be listening for incoming TCP connections to the current virtual IP and port(s).
  • UDP. Enabling this option, the farm will be listening for incoming UDP connections to the current virtual IP and port(s).
  • SIP. Enabling this option, the farm will be listening for incoming UDP connections to the current virtual IP and port 5060 by default, and then will parse the SIP headers for each packet in order to be managed correctly to the backends.
  • FTP. Enabling this option, the farm will be listening for incoming TCP connections to the current virtual IP and port 21 by default, and then will parse the FTP headers for each packet in order to be managed correctly to the backends. Two modes supported: active and passive.
  • TFTP. Enabling this option, the farm will be listening for incoming UDP connections to the current virtual IP and port 69 by default, and then will parse the TFTP headers for each packet in order to be managed correctly to the backends.
  • SCTP. Enabling this option, the farm will be listening for incoming SCTP connections to the current virtual IP and port(s).
  • AMANDA. Enabling this option, the farm will be listening for incoming connections from TCP and UDP protocols to the current virtual IP and port(s) defined (10080, 10081, 10082 and 10083 by default), and then will parse the AMANDA backup service headers for each packet in order to be managed correctly to the backends.
  • H323. Enabling this option, the farm will be listening for incoming connections from TCP and UDP protocols to the current virtual IP and port(s) defined, and then will parse the H323 headers for each packet in order to be managed correctly the VoIP services to the backends.
  • IRC. Enabling this option, the farm will be listening for incoming connections to the current virtual IP and TCP port(s) defined, and then will parse the Internet Relay Chat for chat and file transfer headers for each packet in order to be managed correctly the services to the backends.
  • NetBIOS-NS. Enabling this option, the farm will be listening for incoming connections from TCP and UDP protocols to the current virtual IP and port(s) defined (by default 137 and 138), and then will parse the NetBIOS name service headers for each packet in order to be managed correctly the services to the backends.
  • PPTP. Enabling this option, the farm will be listening for incoming connections to the current virtual IP and TCP port(s) defined, and then will parse the PPTP headers for each packet in order to be managed correctly the services to the backends.
  • SANE. Enabling this option, the farm will be listening for incoming connections from TCP and UDP protocols to the current virtual IP and port(s) defined, and then will parse the scanner service headers for each packet in order to be managed correctly the services to the backends.
  • SNMP. Enabling this option, the farm will be listening for incoming connections from TCP and UDP protocols to the current virtual IP and port(s) defined (by default 161 and 162), and then will parse the SNMP headers for each packet in order to be managed correctly the monitoring services to the backends.

NAT Type. This field indicates the NAT type which means how the layer 4 topology is going to operate. The option that better fits your service and infrastructure will depend on the network architecture defined. By default, the farm will operate in NAT mode.

  • NAT. The NAT mode or commonly named SNAT (source NAT) uses the load balancer IP as the backend connection source IP address, therefore the backend doesn’t know the client IP address at TCP, UDP or any other layer 4 protocol. By this way, the backend responds to the load balancer in order to send the response to the request. This topology permits to deploy a one-armed load balancer (load balancing with just 1 network interface).
  • DNAT. The DNAT (Destination NAT) mode uses the client IP address as the backend connection source IP address, therefore the backend will respond directly to the client IP. In this case, the load balancer IP needs to be configured as the backend default gateway and isolate the backends network from the client service network. This topology is used to perform transparency between clients and backends.
  • DSR.The DSR mode provides an IP transparent method and a MAC level NATting in order to share the inbound packets, meanwhile, the outbound traffic will be delivered directly from the backends to the client. This is the fastest and most performance way to provide load balancing but it doesn’t allow to perform advanced protocol mangling. In this mode, necessarily, the farm’s Virtual IP and the backends must belong to the same network segment and the backends require to be configured with a loopback or dummy network interface with the same IP address than the virtual service and to block the ARP response for the given IP to the loopback interface.
  • STATELESS DNAT. The Stateless DNAT (Stateless destination NAT) mode is a method to provide IP NAT at packet level in a very high-performance way but without using connection tracking. This method is recommended for UDP one-way services or UDP services that don’t need to identify flows. In this case, the load balancer IP needs to be configured as the backend default gateway and isolate the backends network from the client service network. The farms with this type configured do not have statistics to show.

Finally, in order to apply these changes, it’s needed to click on the green Submit button and a confirmation message will appear at the left bottom corner of the browser.

Services for L4xNAT Farm Profile

The service created in L4 layer provides the following options to be configured in order to manage the data path and connections behaviour.

Load Balance Algorithm. This field specifies the load balancing algorithm to be used in order to determine the backend server. By default, the weight algorithm will be the default selected algorithm.

  • Weight: connection linear dispatching by weight. Balance connections depending on the weight value that has been assigned to every backend. The requests are delivered using a probabilistic algorithm using the weight defined.
  • Source Hash: hash per source IP and source port. Balance packets that match the same source IP and port to the same backend using a hash scheduler.
  • Simple Source Hash: hash per source IP only. Balance packets that match the same source IP to the same backend using a hash scheduler.
  • Symmetric Hash: round-trip hash per IP and port. Balance packets that match the same source IP and port and destination IP and port, so it could hash a connection in both ways (during inbound and outbound).
  • Round robin: sequential backend selection. Balance the connections or packets sequentially as a list between the backends, although it could be complemented with weight values.

Finally, in order to apply this change, it’s needed to click on the green Submit button and a confirmation message will appear at the left bottom corner of the browser.

In regards to the Farm Guardian section, L4xNAT farms don’t provide an intrinsic health check to the backends so the Farm Guardian configuration is required for this kind of virtual services.
Some built-in or customized advanced health checks already created can be assigned by selecting it in the drop-down

For further information about Farm Guardian go to the Monitoring >> Farm Guardian section.

In order to apply the change in FarmGuardian is not needed to click the Submit button, the change will be done automatically.

In regards to the Backends section, the L4xNAT farm profile allows to configure the following real servers properties:

ID. It’s the index that references the backend in the farm configuration.
IP. The IP address of the given backend.
WEIGHT. It’s the weight value for the current real server which is only useful if the Weight Algorithm is enabled. More weight value indicates more connections delivered to the current backend. By default, a weight value of 1 will be set. The values range available are from 1 to 9.
PRIORITY. It’s the priority value for the current real server which is only useful if the Priority Algorithm is enabled. The priority value accepted is between 0 and 9, less value indicates more priority to the current real server. By default, a priority value of 1 will be set. The values range available are from 1 to 9.

This section will let you:

  • Add Backend. Add a new real server into the farm.
  • Save. Save the new real server entry in the given farm and start using it.
  • Close. Cancel the new real server entry.
  • Enable Maintenance. Put a certain real server in maintenance mode, so no new connections will be redirected to it. There are two different methods to enable Maintenance:
    • Drain Mode. Keeps established connections and persistence if enabled, but will not admit new connections.
    • Cut Mode. Directly drops all active connections against the backend
  • Start. Enable new connections to the real server again after the enabled maintenance.
  • Delete. Delete the given real server of the virtual service.
  • Edit. Modify a certain value of the real server.

In order to apply the change in backends is not needed to click the Submit button, the change will be done automatically.

Share on:

Documentation under the terms of the GNU Free Documentation License.

Was this article helpful?

Related Articles