Load balancing FAQ

Server load balancing

Q.     When an LB policy and a default server farm are specified for a Layer 7 virtual server, how does the virtual server process traffic?

A.     The policy takes precedence over the default server farm.

Based on the LB policy and server farm configuration, the virtual server processes traffic as follows:

·     When a server farm is specified for the LB action, the virtual server forwards traffic through real servers in the server farm.

·     When no server farms are specified for the LB action or the specified server farm does not exist, the virtual server discards traffic.

·     When no LB actions are specified for the policy or the specified policy does not exist, the virtual server forwards traffic though the default server farm.

Q.     How does HTTP NAT64 work?

A.     HTTP virtual servers support NAT64, which works as follows:

Client------------(IPv4)--------->LB----------(IPv6)-------->Server

Client------------(IPv6)--------->LB----------(IPv4)-------->Server

·     Typically, the HTTP server uses the same IP version as the client to implement load balancing. For example, the device will use an IPv4 address to connect an IPv4 client to a dual-stack server (that supports both IPv4 and IPv6). When the server IPv4 address is unreachable, .upon receiving a client IPv4 request, the device still uses an IPv4 address to connect to the backend server. To avoid this issue, as a best practice, configure health monitoring for the real server to detect server reachability.

·     NAT64 depends on the specified SNAT address pool. For NAT64 to translate an IPv4 address into an IPv6 address to connect to the server, you must configure IPv6 SNAT for the server farm.

Q.     What are the restrictions and guidelines for configuring virtual servers?

A.     A virtual server is available for use after you configure an IP address and enable service for it. Redirection to the virtual server do not require server farm or policy configuration. Packets enter the LB process as long as they match an available virtual server.

A virtual server can identify a service by its transport layer protocol (such as TCP and UDP), VPN, IP address, port number, and mask. The combination of such information must be unique for a virtual server.

TCP, HTTP, and fast HTTP virtual servers use TCP as the Layer 4 protocol. For correct packet matching and forwarding, make sure the combination of VPN, IP address, port number, and mask is unique for a TCP, HTTP, or fast HTTP virtual server. When the specified combination is not unique, the CLI displays an error message.

For an IP or UDP virtual server, if the combination of IP address, port number, and mask is the same as that of other types of virtual servers, the device selects a virtual server for matching packets. As a best practice, make sure the combination of IP address, port number, and mask for an IP or UDP virtual server is unique.

To conclude, make sure the combination of VPN, VSIP, and port number for an IP, TCP, HTTP, or fast HTTP virtual server is unique among virtual servers of different types. This can ensure the LB device to process packets correctly.

Q.     What are the restrictions and guidelines for configuring LB policies and sticky methods?

A.     Generic LB policies can use only generic LB classes and LB actions. HTTP LB policies can use any LB classes and LB actions.

Layer 4 virtual servers cannot use Layer 7 sticky methods, policies, or parameters. If you specify Layer 7 sticky methods, policies, or parameters for a Layer 4 virtual server, the configuration does not take effect.

Q.     How can I locate the issue when HTTPS offloading traffic cannot be transmitted?

A.     Perform the following tasks:

·     When the virtual server uses an SSL policy, you must specify a non-default port number (typically 443) for the virtual server to make sure the traffic can be correctly processed.

·     After the SSL configuration is edited, the virtual server cannot detect it. To apply the SSL configuration to the virtual server, manually execute the undo service enable and service enable commands on the virtual server.

·     Identify whether the port number specified for the real server is the same as that used on the server.

Q.     What are the differences between cookie insert and cookie rewrite sticky methods?

A.     Cookie write requires response packets from the server to carry the specified set-cookie or set-cookie2 fields in the header. The LB device rewrites the value of such fields before sending the packets to the client.

Cookie insert do not have such requirement.

Q.     How do the cookie insert and cookie rewrite sticky methods work?

A.     When a virtual server or LB policy uses cookie insert, the LB device inserts the set-cookie field into the packets to the client. Request packets from the client carrying such a field match a sticky entry and are forwarded to the corresponding server.

When a virtual server or LB policy uses cookie rewrite, the LB device rewrites the set-cookie field in the response packets to the client. Request packets from the client carrying such a field match a sticky entry and are forwarded to the corresponding server.

Q.     What are the restrictions and guidelines for configuring the maximum number and minimum number of real servers to participate in scheduling?

A.     After you configure the maximum number and minimum number of real servers to participate in scheduling, the real servers participate in scheduling as follows:

·     When the total number of real servers in a server farm is smaller than the specified minimum number, all real servers participate in scheduling.

·     If the number of real servers available to participate in scheduling is less than the specified minimum number, more real servers are selected by priority. The total number of real servers available to participate in scheduling cannot exceed the specified maximum number.

Q.     Which scheduling algorithms does the real server weight apply to?

A.     The real server weight applies to weighted round robin, bandwidth algorithm, weighted least connection algorithm (for real servers), and weighted least connection algorithm (for server farm members).

Q.     When the fault processing method is to terminate the connection, which additional commands do I need to execute for UDP and ICMP traffic?

A.     Execute the ip unreachables enable command in system view to enable sending connection termination messages to the client.

Q.     How can I configure session backup for an IRF fabric?

A.     In an IRF fabric with LB enabled, you must configure the session sync and connection-sync commands to enable session synchronization between the master and subordinate devices. Typically, this feature is required, and you must configure these commands.

Layer 7 virtual servers do not support these commands.

Q.     Which health monitoring methods and dynamic proximity probing does load balancing support?

A.     Server load balancing supports all NQA templates for monitoring server farms and real servers.

Outbound link load balancing supports all NQA templates for monitoring server farms and real servers.

Outbound link load balancing supports the LB probe template for dynamic proximity probing.

Inbound link load balancing supports all NQA templates for monitoring links.

Outbound link load balancing

Q.     After I configure the fallback-action continue command for an LB action, what happens upon failure to find an available link?

A.     This command enables packets to match the next rule upon failure to find an available link.

Q.     When a packet is forwarded based on an LB policy, the packet matches the LB classes and actions by configuration sequence. When an LB class is matched, the device performs the associated action. What happens when the packet fails to match an LB class?

A.     By default, a packet that does not match the first LB class in the LB policy tries to match the next LB class.

Q.     How can I test link busyness?

A.     A link is considered busy when the currently used bandwidth is greater than the product of the specified maximum expected bandwidth and the specified bandwidth ratio.

You can obtain the currently used bandwidth as follows:

·     Obtain the currently used bandwidth from the link statistics.

·     Obtain the currently used bandwidth from the interface.

This method requires enabling (on the virtual server) bandwidth statistics collection by interface and the link protection feature. After that, the traffic size is obtained from the interface at 300-second intervals by default. Only when the link is associated with a physical port, you can use the flow-interval command to set the statistics interval.

New connections are not distributed to busy links. Existing connections are not affected. When a link is not busy, new connections are distributed to it.

Follow these restrictions and guidelines when you use this feature:

·     Link protection requires you to set the maximum expected bandwidth (with the max-bandwidth command).

·     You can set the maximum bandwidth for a link (with the rate-limit bandwidth command). After that, the link is considered busy when the currently used bandwidth is greater than the product of the specified maximum expected bandwidth and the specified bandwidth ratio. When all the links are busy and the maximum bandwidth is specified, the interface will drop traffic that exceeds the specified bandwidth value.

·     Link protection applies to only the outbound direction of the output interface. It affects only outgoing requests from the client.

·     A busy outbound link does not have debugging information.

·     After you specify the inbound direction, outbound direction, or both directions for link protection, if traffic size exceeds the threshold on one direction, the link is considered busy.

The following symptoms might occur during the test:

·     For a busy link, the traffic statistics in the outbound direction of the output interface displays 0. This is probably because no subsequent packets were captured from the link.

·     After you configure the max-bandwidth and bandwidth busy-rate commands for a link, the inbound and outbound statistics are for only the output interface. The outbound traffic is limited based on the specified maximum bandwidth and bandwidth rate. The inbound traffic is not limited.

Q.     For a link with the highest priority in a link group, what happens if the traffic size of the link reaches the threshold or the connection count reaches the limit?

A.     When the connection count of the link with the highest priority reaches the upper limit in a link group, the virtual server discards the new packets rather than distributes the connections to other links, even if the links are specified to participate in scheduling.

Q.     What happens after I configure the highest priority for a link in a link group and specify links to participate the scheduling?

A.     Upon failure or probe failure of the link with the highest priority, a link with lower priority is selected.

Q.     What are bandwidth algorithm and maximum bandwidth algorithm?

A.     The information about bandwidth algorithm and maximum bandwidth algorithm are described as follows:

·     Bandwidth algorithm

The bandwidth algorithm distributes traffic to real servers according to the remaining bandwidth and weight of the real servers.

To configure the bandwidth algorithm:

a.     Enter virtual server view.

virtual-server virtual-server-name

b.     Enable bandwidth statistics collection by interface.

bandwidth interface statistics enable

By default, bandwidth statistics is collected by load balancing.

The remaining bandwidth equals the maximum bandwidth minus the currently used bandwidth.

To test the bandwidth of a link, you must set the maximum bandwidth for the link with the rate-limit bandwidth [ inbound | outbound ] bandwidth-value command. This command sets the maximum bandwidth of a real server and does not affect the interface bandwidth.

You can execute the bandwidth interface statistics enable command on the virtual server to enable bandwidth statistics collection by interface. After that, the real server uses the bandwidth collected by interface (with the real server IP address) as its currently used bandwidth, rather than using the bandwidth statistics from the LB device. (The LB device collects the total size of packets distributed to the link by the LB device at 1-second intervals. The link bandwidth is the value collected in the previous second.)

For example, when the weight for rs1 is 3 (remaining bandwidth 100 Mbps), the weight for rs2 is 2 (remaining bandwidth 200 Mbps), and the weight for rs3 is 1(remaining bandwidth 300 Mbps), traffic is distributed to them as follows:

rs1 traffic : rs2 traffic : rs3 traffic=3 × 100 : 2 × 200 : 1 × 300

This example is for illustration only. The actual implementation might be different.

·     Maximum bandwidth algorithm

The maximum bandwidth algorithm distributes user requests always to an idle real server that has the largest remaining bandwidth.

The total bandwidth of a real server is specified by using the rate-limit bandwidth command regardless whether bandwidth statistics collection by interface is enabled.

When bandwidth statistics collection by interface is enabled for the virtual server, the currently used bandwidth takes the last-second value on the interface. When bandwidth statistics collection by interface is disabled, the current used bandwidth takes the value of the Throughput field in the output from the display real-server statistics command.

You can configure the flow-interval command to set the interface statistics interval. For example, configure flow-interval 5 to set the statistics interval to 5 seconds.

The LB device collects interface statistics at 1-second intervals to obtain the currently used bandwidth. Based on the total bandwidth (specified with the rate-limit bandwidth command), it calculates the remaining bandwidth by using the total bandwidth minus the currently used bandwidth.

For example, the minimum collection interval of interface statistics is 5 seconds. During this interval, only one interface has the minimum traffic, so that only real server rs1 is selected in the 5 seconds. During the next 5 seconds, the statistics shows rs1 has a relatively large traffic, so that the device selects another real server with the largest remaining bandwidth. To conclude, during a 5-second interval, only one real server is selected. During the next 5-second interval, a real server with the largest remaining bandwidth is selected.

In some scenarios, only a few links have traffic among multiple links. This is because the maximum bandwidth algorithm always selects the real server with the largest remaining bandwidth from the server farm. When multiple real servers have the same remaining bandwidth, the LB device selects a real server according to configuration order. If the remaining bandwidth for the real server becomes the largest again at the next interval, it is selected again. Other real servers might always have a relatively small remaining bandwidth and are not selected.

Q.     After I enable dynamic proximity and set the link priority, what happens when dynamic proximity determines that the link priority is low?

A.     Dynamic proximity selects a link with high priority as the optimal link.

Q.     What is the order that last hop holding, static routing, and policy based routing take effect?

A.     The last hop holding, policy based routing, and static routing take effect in a descending order of priority.

Q.     When both the proximity and sticky entries are configured, which one applies to traffic distribution?

A.     The sticky entry applies first. When no match is found, the proximity entry applies. When no match is found again, the scheduling algorithm applies.

When both stickiness and proximity are enabled, but no sticky entry or proximity entry exists, a sticky entry is generated first based on the algorithm. Then a proximity entry is generated based on the probe result.

Q.     How do a proximity entry and the link bandwidth limit affect each other during link selection?

A.     After you set the bandwidth limit for a link, even if the link is optimal based on the proximity entry, the link might not be selected due to bandwidth limit. When the link bandwidth in use drops below the limit, it can be selected.

Q.     What happens if I edit the proximity probe method when proximity entries exist?

A.     This operation clears all proximity entries. When new packets arrive, the new proximity probe method applies.

Q.     Why aren't proximity entries generated after I enable the proximity feature for the link group?

A.     Identify whether you have specified the proximity probe method for the feature.

Proximity entries are generated through proximity probes. If you do not specify a valid proximity probe method, no proximity entries can be generated.

Q.     Does editing the cost, RTT, or bandwidth for the link affect the proximity entries?

A.     When a proximity-related parameter change affects link selection, the proximity entries are updated and a new optimal link is determined. After you manually clear the proximity entries or the proximity entries expire, they are deleted.

Q.     Why do proximity entries still exist after I disable the proximity feature for all link groups?

A.     Proximity entries apply to all link groups. After I disable the proximity feature for all link groups, the proximity entries are not immediately deleted. No new proximity probes are performed and the entries do not take effect. After you manually clear the proximity entries or the proximity entries expire, they are deleted.

Q.     Why aren't proximity entries generated for SIP traffic?

A.     If sessions already exist, traffic is forwarded by session without performing proximity probes.

If no sessions exist and the session relation table exists, the first packet will match a session relation entry to establish a session. Subsequent packets are forwarded along the session.

Subsessions are established based on the session relation table for forwarding subsequent packets.

Q.     If a link is not specified for a link group, what is the state of the link?

A.     When a link is specified for a link group, the link is limited by the outbound link LB configuration. If the outbound link LB configuration is not complete, the link state is inactive.

When a link is not specified for by a link group, but it has an IP address and a probe is triggered, the link state is determined by the probe. If no probes are triggered, the link state is unknown.

Q.     How does link protection affects the link selection algorithm?

A.     Suppose the maximum bandwidth algorithm is specified for a link group, and link group member link1 with bandwidth ratio configured has the largest remaining bandwidth.

Based on the maximum bandwidth algorithm, user requests are distributed to link1. When the bandwidth of link1 exceeds the threshold, new user requests are distributed to link2. When the bandwidth of link1 drops below the threshold, new user requests are distributed to link1 if it has the largest remaining bandwidth.

Configure the proximity feature for the link group. When the bandwidth of link1 exceeds the threshold, link1 does not participate in the scheduling algorithm and proximity probing. When the bandwidth of link1 drops below the threshold, link1 participates in the scheduling algorithm and proximity probing.

Configure the stickiness feature for the link group and link protection for link1. When a user request matches a sticky entry associated with link1, link protection does not take effect. User request are still distributed to link1 based on the sticky entry.

A link is considered busy when the ratio of the used bandwidth to the expected maximum bandwidth exceeds the bandwidth ratio. The default bandwidth ratio is 70%. When all links are busy, link protection does not take effect and the specified scheduling algorithm applies. User requests are distributed to link1 only after the ratio of the used bandwidth to the expected maximum bandwidth drops below the bandwidth recovery ratio.

Q.     Are there any suggestions for configuring LB health monitoring parameters?

A.     The suggestions are as follows:

1.     Make sure the frequency is larger than the probe timeout time.

2.     The fault switchover time is calculated with the formula: (Number of consecutive probe failures to determine an operation failure - 1 ) × frequency + probe timeout time

3.     The maximum recovery time is calculated with the formula: Frequency × number of consecutive successful probes to determine a successful operation event

4.     To avoid network flapping, do not set a small value for the frequency, probe timeout time, or number of consecutive probe failures to determine an operation failure.

Q.     During the test, no proximity entries or no expected links exist. How can I locate the issue?

A.     Perform the following tasks:

1.     Identify whether the proximity feature is configured for the link group that the traffic matches.

2.     Identify whether a probe method is specified for the proximity feature.

3.     Identify whether the link state is active.

4.     Identify whether the link has reached the specified thresholds (if any), such as bandwidth limit, connection count limit, and busy rate.

Q.     During the test, the optimal link in a proximity entry has changed. How can I locate the issue?

A.     Perform the following tasks:

1.     The optimal link might be removed. Troubleshoot this issue as described in "During the test, no proximity entries or no expected links exist. How can I locate the issue?"

2.     Set the bandwidth weight to 0 and observe whether the issue is caused by large traffic size.

Transparent DNS proxies

Q.     When I use a transparent DNS proxy, can I specify the client DNS address as the LB device interface address?

A.     When the transparent DNS proxy is 0.0.0.0, if you specify the client DNS address as the LB device interface address, the DNS proxy does not take effect. As a best practice, do not specify the client DNS address as the LB device interface address.

If you need to specify the client DNS address as the LB device interface address, you must specify the address (with a 32-bit mask) also in DNS proxy view. In the current software version, as a best practice, specify both the DNS proxy address and web address as 0.0.0.0.

Intelligent DNS (inbound link load balancing)

Q.     How many types of intelligent DNS proximity algorithms are there?

A.     In the current software version, proximity algorithms are categorized into two types, static proximity algorithm (topology) and dynamic proximity algorithm (proximity).

Q.     How can I specify the priority of the scheduling algorithms for a virtual server pool?

A.     You can specify one preferred scheduling algorithm, one alternative scheduling algorithm, and one backup scheduling algorithm for a virtual server pool. If no virtual server can be selected by using the preferred scheduling algorithm, the alternative scheduling algorithm is used. If no virtual server can be selected by using the alternative scheduling algorithm, the backup scheduling algorithm is used.

Q.     The session backup feature failed to back up intelligent DNS packets. Why does this happen?

A.     Execute the session synchronization dns http and session synchronization enable commands in system view to enable session backup.

Display the session entries collected on a per slot basis. Statistics collection for UDP DNS traffic session backup is not necessary. One request is typically associated with one response.

Q.     I have specified the preferred scheduling algorithm as topology and left the alternative and backup scheduling algorithms unspecified. When the link associated with the preferred virtual server meets the link protection conditions, how are subsequent user requests processed?

A.     When the link associated with a virtual server meets the link protection conditions, a virtual server without link protection triggered is selected from the topology by packet source IP address.

When no matching virtual server is found from the topology, the virtual server selection fails. To avoid this issue, you must specify the alternative and backup scheduling algorithms.

Q.     After I specify the preferred scheduling algorithm as proximity, packet loss occurs. How can I deal with this issue?

A.     The dynamic proximity algorithm immediately generates proximity entries once triggered by packets. An entry becomes available in 10 seconds after it is generated. During the 10 seconds, DNS requests are denied. To avoid this issue, you must specify the alternative and backup scheduling algorithms to ensure service processing. When the entry becomes available, the preferred scheduling algorithm applies.

Security policies

Q.     Do I have to configure security policies for the LB device?

A.     No. You do not need to configure security policies for the LB device.