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. Only from version 5.10. In Stateless DNAT the load balancer switches destination address for the backend address and forward it to the backend as DNAT does, but it doesn’t manage any kind of connection information. DNAT configuration reduces the load on the system since it is performed in an early data path, being the most indicated NAT mode for layer 4 protocols with high load and not connection-oriented nor stream-oriented protocols as it is RTP.
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.
Persistence. Only from version 5.10 The persistence options are the following.
Persistence Mode. This field determines if any persistence is used in the configured farm. By default, no persistence is used.
- No persistence. The farm will not use any kind of persistence between the client and the backend.
- IP: Source IP. With this option, the farm will assign the same backend for every incoming connection depending on the source IP address only.
- Port: Source Port. With this option, the farm will assign the same backend for every incoming connection depending on the source port only.
- MAC: Source MAC. With this option, the farm will assign the same backend for every incoming connection depending on link-layer MAC address of the packet.
- Source IP and Source Port. With this option, the farm will assign the same backend for every incoming connection depending on both, source IP and source port.
- Source IP and Destination Port. With this option, the farm will assign the same backend for every incoming connection depending on both, source IP and destination port.
Persistence Session Time to Live. If any persistence is selected, this field value indicates the number of seconds that the persistence between the client source and the backend is being assigned.
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.
Port. Only from version 5.10. Port to be used when forwarding traffic to the 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.