Configuring a Virtual Service

Procedure

1. In the user view, access the system view.

   system-view

2. Access the SLB configuration view.

   slb

3. Create a virtual server or access the virtual server view.

   vserver [ vserver-id ] vserver-name

   If you do not set an ID for a virtual server when creating it, the FW assigns an ID to it.

4. Configure a protocol type for the virtual server.

   protocol { any | tcp | udp | http | https | ssl | ssl | esp }

   By default, a virtual server supports all protocols (any).

   To improve server security, you are advised to set the protocol type based on services.

5. Optional: Run the ssl-profile command to reference an SSL uninstallation profile.

   The SSL uninstallation profile is only referenced when the virtual service protocol is HTTPS.

6. Set an IP address for the virtual server.

   vip [ start-vip-id [ to end-vip-id ] ] ip-address

   

   The IP address of a virtual server is usually a public IP address to which users send service requests.

   When SLB is configured in the root system, the IP address must be different from any of the following IP addresses:

   • IP address in the NAT address pool

   • Public IP address (global-ip) assigned to the virtual system

   • IP address of the gateway

   When SLB is configured in a virtual system, the virtual server IP address must be a public IP address (global IP address) different from any of the following IP addresses:

   • IP address in the NAT address pool

   If you do not set an ID for a virtual server when setting an IP address for it, the FW assigns an ID to it. When modifying the IP address of a virtual server, you must specify the ID.

   Multiple IP addresses can be set for a virtual server to provide services for different network segments. You can run the vip ip-address command multiple times to configure IP addresses of different network segments for the virtual server.

   The vip start-vip-id to end-vip-id ip-address command is used to set IP addresses for a virtual server in batch. For example, use the vip 1 to 5 1.1.1.1 command to set IP addresses 1.1.1.1 to 1.1.1.5 for a virtual server. The ID mapping 1.1.1.1 is 1, the ID mapping 1.1.1.2 is 2, and so on.

7. Set a port number for the virtual server.

   vport { any | port-number }

   By default, a virtual server uses a random port number (any).

   

   If the protocol type is set to any and ESP, the port number cannot be set for the virtual server.

8. Optional: Run the persistence persistence-name command to reference a sticky session profile.

   If the virtual server protocol is SSL, the sticky session mode can be session-id or source-ip. If the virtual server protocol is HTTP or HTTPS (SSL uninstallation must be configured for HTTPS), the sticky session mode can be cookie or source-ip. If the virtual server protocol is another protocol, the sticky session mode can only be source-ip.

   If many clients access the server through the proxy or Source NAT, the sticky session mode source-ip is not preferred. If source-ip is set, the connections of all clients are allocated to one real server, causing server load unbalancing.

9. Optional: Run the httpclass httpclass-name command to reference an HTTP scheduling policy profile.

   When the virtual server protocol type is HTTP, the httpclass httpclass-name command can be used to reference an HTTP scheduling policy profile. HTTP access requests of different types (URL, HOST, Referer, and Cookie) match with the HTTP scheduling policy profiles. Load balancing is implemented in the group associated with the HTTP scheduling policy profiles. Each virtual server can reference a maximum of eight HTTP scheduling policy profiles. The priority is matched according to the reference sequence. If an HTTP scheduling policy profile of high priority is matched successfully, it does not go on matching. The httpclass move command is used to adjust the matching priority of an HTTP scheduling policy profile.

   When the virtual server protocol type is HTTPS, this command enables the load balancing function if SSL uninstallation is enabled.

10. Associate the virtual server and the real server group.

    group group-name

    A virtual server can be associated with only one real server group.

    

    If service traffic matches an HTTP Scheduling Policy, the FW preferentially allocates the service traffic to the real server group configured in the HTTP scheduling policy.

    The configuration of the associated virtual server cannot conflict with the real server group configuration. To be specific, the protocol configuration of the virtual server cannot conflict with the sticky session or health check configuration of the real server group. For details, see Table 1.

    Table 1 Virtual and real server configuration conflict check items

    Protocol configuration of the virtual server		any	http	https	ssl	tcp	udp	esp
    Sticky session configuration of the real server group	source-ip	√	√	√	√	√	√	√
    	session-id	×	×	×	√	×	×	×
    	cookie	×	√	√	×	×	×	×
    Health check configuration of the real server group	dns	√	×	×	√	√	√	√
    	https	√	×	√	√	√	×	√
    	http	√	√	√	×	√	×	√
    	icmp	√	√	√	√	√	√	√
    	radius	√	×	×	×	×	√	√
    	tcp	√	×	×	√	√	×	√
    √: not conflict ×: conflict

    After configuring an IP address for the virtual server, associate the virtual server with the real server. The FW will automatically generate a black-hole route for the IP address of the virtual server to prevent routing loops. View the routing table. You can find the routing entry whose the destination IP address is the IP address of the virtual server, the mask length is 32 bits, and next-hop address is the address of null 0. After you delete the IP address of the virtual server or cancel the binding between the virtual and real servers, the black-hole route will be automatically deleted.

11. Optional: Run the fallback command to create a fallback host for a virtual server.

    If no fallback host is specified, the virtual server will be disconnected when no real server is available in the real server group associated with the virtual server. When the function is enabled, the FW redirects the client-side access requests to the fallback host. The real servers in the real server group are unavailable in the following states:

    • The server is in Inactive or Admin-Invalid state.
    • The number of connections to the real servers reaches the upper limit, and the policy for busy real servers is re-scheduling.

    The fallback host function can be configured only when the virtual server protocol is HTTP or HTTPS (SSL offloading is required for HTTPS).

12. Optional: Enable the HTTP X-Forward function.

    http x-forward enable

    After this function is enabled, the FW inserts the X-Forwarded-For field into the HTTP header of each HTTP packet sent from the client. This field carries the real IP address of the client to the real server that supports X-Forwarded-For.

    This function can be enabled only after the protocol command is run to set the virtual server protocol to HTTP. After the virtual server protocol is changed to another protocol, the HTTP X-Forward function is automatically disabled.

    If FW translates the source addresses of the traffic destined to the real server, use the source NAT function of the server load balancing module instead of the global source NAT function. Otherwise, the address stickiness function of the client cannot take effect.

13. Optional: Run the max-connection command to configure the maximum number of connections on a virtual server.

    By default, the maximum number of connections on a virtual server is 0 with no limit.

    When the number of concurrent connections on a virtual server reaches max-connections-value, the FW no longer allocates new connections to the server. At the same time, the FW sends the log FW_SLB/5/VSERVER_OVERLOADED to inform the administrator of the server overload. After the number of concurrent connections on the virtual server falls below 80% of max-connections-value, the FW sends the log FW_SLB/6/VSERVER_NORMALRUNl to inform the administrator of the server restoration.

14. Optional: Bind the virtual server to the VRRP group.

    vrrp virtual-router-id

    SLB does not apply to load balancing scenarios in hot standby deployment. If the device works in active/standby mode or mirroring mode and the IP address of the virtual server is not on the same network segment as that of the VRRP group, you do not need to run this command. If these two IP addresses are on the same network segment, you need to run this command and set virtual-router-id to the ID of the VRRP group corresponding to the inbound interface.

    Before changing the VRRP group to which a virtual server is bound, cancel the binding between the virtual and real servers. Then run the vrrp virtual-router-id command to bind the virtual server to a new VRRP group.

15. Return to the user view.

    return