Direct Server Return (DSR) SLB Deployment

This chapter provides additional deployment examples for Server Load Balancing (SLB). The following types of deployment are shown:

     Direct Server Return in Transparent Mode 

     Direct Server Return in Route Mode 

     Direct Server Return in Mixed Layer 2/Layer 3 Environment

     Layer 3 Direct Server Return (IP Tunneling)

Direct Server Return in Transparent Mode

This section contains the following:

     Overview of DSR in Transparent Mode

     DSR in Transparent Mode Configuration Example

Overview of DSR in Transparent Mode

FIGURE 33    shows an example of an ACOS device deployed in transparent mode, in a Direct Server Return (DSR) configuration. In a DSR configuration, replies from real servers do not necessarily pass through the ACOS device.

FIGURE 33         ACOS Deployment Example – DSR in Transparent Mode

deploy_dsr_transparent.png

 

In this example, the ACOS device is attached to the network in a “one-armed” configuration. A single link connects the ACOS device to the network. The link can be on a single Ethernet port or a trunk. This example uses a single Ethernet port.

The arrows show the traffic flow for client-server traffic; in this example, between clients and servers 192.0.2.3-4. Client request traffic for the virtual server IP address, 192.0.2.99, is routed to the ACOS device. However, server reply traffic does not pass back through the ACOS device.

DSR Health Checking

Layer 3 and Layer 4-7 health checks are supported in DSR configurations.

The target of the Layer 3 health checks can be the real IP addresses of the servers, or the virtual IP address, depending on your preference.

     To send the Layer 3 health checks to the real server IP addresses, you can use the default Layer 3 health method (ICMP).

     To send the Layer 3 health checks to the virtual IP address instead:

     Configure an ICMP health method with the transparent option enabled, and with the alias address set to the virtual IP address.

     Globally enable DSR health checking.

Layer 4-7 health checks are sent to the same IP address as the Layer 3 health checks, and then addressed to the specific pro­tocol port. You can use the default TCP and UDP health monitors or configure new health monitors. This example uses the default TCP health monitor.

Requirements for DSR in Transparent Mode Deployment

This configuration has certain requirements:

     Requirements on the ACOS device:

     The ACOS device, virtual server, and the real servers all must be in the same subnet.

     The virtual server IP address must be configured as a loopback interface on each real server. (This is performed on the real server itself, not as part of the real server’s configuration on the ACOS device.)

     DSR must be enabled on the virtual service ports. (Enabling DSR is equivalent to disabling destination NAT on the return traffic. This allows real servers to respond directly to clients, bypassing the ACOS device and retaining the IP address of the real server in the response to the client.)

NOTE:                               In the current release, for IPv4 VIPs, DSR is supported on virtual port types (service types) TCP, UDP, FTP, and RTSP. For IPv6 VIPs, DSR is supported on virtual port types TCP, UDP, and RTSP.

     Requirements on the real server:

     A loopback interface must be configured with the virtual server IP address.

     ARP replies from the loopback interfaces must be disabled. (This applies to the loopback interfaces that have the virtual server IP address.)

DSR in Transparent Mode Configuration Example

This section shows how to use the GUI to configure the topology shown in Figure 33:

     Using the GUI to Configure DSR in Transparent Mode

     Use the CLI to Configure DSR in Transparent Mode

Using the GUI to Configure DSR in Transparent Mode

Configuring the topology shown in Figure 33 using the GUI involves the following steps:

     Configure the IP Address and Default Gateway

     Enable Ethernet Interfaces

     SLB Configuration - Real Servers

     SLB Configuration - Service Group

     SLB Configuration - Virtual Port and Enabling DSR

NOTE:                               This example does not include configuration of the real servers, or configuration of the virtual server, other than the steps need to enable DSR.

Configure the IP Address and Default Gateway

To configure the IP address and default gateway:

1.     Navigate to Network >> Interfaces >> Transparent.

2.     Enter 192.0.2.2 in the IP Address field.

3.     Enter 255.255.255.0 in the IP Mask field.

4.     Enter 192.0.2.1 in the Default Gateway field.

5.     Click Configure.

Enable Ethernet Interfaces

To enable the interfaces:

1.     Navigate to Network >> Interfaces >> LAN.

2.     On the menu bar, select the LAN tab, if not already displayed.

3.     Select the checkbox in the row for e1, then click Enable.

SLB Configuration - Real Servers

To configure the real servers:

1.     Navigate to ADC >> SLB >> Servers.

2.     Click Create.

3.     Enter rs1 in the Name field.

4.     Enter 192.0.2.3 in the Host field

5.     In the Port section, click Create.

a.     Enter 80 in the Port Number field.

b.     Click Create.

6.     Click Update.

Repeat this procedure to create server rs2, with the IP address 192.0.2.4.

SLB Configuration - Service Group

To configure the service group:

1.     Navigate to ADC >> SLB >> Service Groups.

2.     Click Create.

3.     Enter sg-web in the Name field.

4.     In the Member section, click Create.

a.     Select rs1 from the drop-down list in the Server field.

b.     Enter 80 in the Port field.

c.     Click Create.

d.     Repeat to add server rs2 as a member.

5.     Click Update.

SLB Configuration - Virtual Port and Enabling DSR

1.     Navigate to ADC >> SLB >> Virtual Servers.

2.     Click Create.

3.     Enter vip1 in the Name field.

4.     Enter 192.0.2.99 in the IP Address field.

5.     In the Virtual Port section, click Create.

a.     Enter 80 in the Port field.

b.     Expand the General section, then click the checkbox in the No Dest NAT field.

c.     Click Create.

6.     Click Update.

Use the CLI to Configure DSR in Transparent Mode

This section shows how to use the CLI to configure the topology shown in Figure 33:

     Configuring the IP Address and Default Gateway

     Enabling the Ethernet Interfaces

     SLB Configuration - Real Servers

     SLB Configuration - Service Group

     SLB Configuration - Virtual Server and Enabling DSR

     Configuration on the Real Servers

Configuring the IP Address and Default Gateway

The following commands configure the global IP address and default gateway:

ACOS(config)# ip address 192.0.2.2 /24

ACOS(config)# ip default-gateway 192.0.2.1

 

Enabling the Ethernet Interfaces

The following commands enable the Ethernet interface connected to the clients and server:

ACOS(config)# interface ethernet 1

ACOS(config-if:ethernet:1)# enable

ACOS(config-if:ethernet:1)# exit

 

SLB Configuration - Real Servers

To configure real servers rs1 and rs2:

ACOS(config)# slb server rs1 192.10.2.3

ACOS(config-real server)# port 80 tcp

ACOS(config-real server-node port)# exit

ACOS(config-real server)# exit

ACOS(config)# slb server rs2 192.0.2.4

ACOS(config-real server)# port 80 tcp

ACOS(config-real server-node port)# exit

ACOS(config-real server)# exit

 

SLB Configuration - Service Group

To configure the service group sg-web with port 80 on rs1 and rs2 as members:

ACOS(config)# slb service-group sg-web tcp

ACOS(config-slb svc group)# member rs1 80

ACOS(config-slb svc group-member:80)# member rs2 80

ACOS(config-slb svc group-member:80)# exit

 

SLB Configuration - Virtual Server and Enabling DSR

To configure the virtual server vip1 and enable DSR:

ACOS(config)# slb virtual-server vip1 192.0.2.99

ACOS(config-slb vserver)# port 80 tcp

ACOS(config-slb vserver-vport)# service-group sg-web

ACOS(config-slb vserver-vport)# no-dest-nat

 

Configuration on the Real Servers

For DSR to work, a loopback interface with the IP address of the virtual server must be configured on each real server, and ARP replies from the loopback address must be disabled.

For example, on a Unix/Linux server:

ifconfig lo:0 192.0.2.99 netmask 255.255.255.255 -arp up

echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

echo 2 > /proc/sys/net/ipv4/conf/eth0/arp_announce

 

Direct Server Return in Route Mode

This section contains the following:

     Overview and Topology of DSR in Route Mode

     Configuring DSR in Route Mode

Overview and Topology of DSR in Route Mode

FIGURE 34    shows an example of an ACOS device deployed in a DSR configuration in route mode.

FIGURE 34         ACOS Deployment Example – DSR in Route Mode

deploy_dsr_route.png

 

The configuration is very similar to the one for DSR in transparent mode, except the ACOS device uses an IP interface config­ured on an individual Ethernet port instead of a global IP address.

The requirements for the ACOS device and real servers are the same as those for DSR in transparent mode. (See Direct Server Return in Transparent Mode.)

 

Configuring DSR in Route Mode

This section shows how to implement the configuration shown in Figure 34.

NOTE:                               Only the configuration that differs from deployment of DSR in transparent mode are shown; for the remainder of the configuration, see Using the GUI to Configure DSR in Transparent Mode or Use the CLI to Configure DSR in Transparent Mode.

     Use the GUI to Configure DSR in Route Mode

     Use the CLI to Configure DSR in Route Mode

Use the GUI to Configure DSR in Route Mode

The following configuration procedures differ from the instructions provided in Using the GUI to Configure DSR in Transparent Mode:

     Configure an IP Address on the Ethernet Port

     Configure a Default Route

Configure an IP Address on the Ethernet Port

To configure an IP Address in the ethernet interface:

1.     Navigate to Network > Interfaces >> LAN.

2.     In the Actions column, click on the Edit link for interface e3.

3.     Select the Enabled radio button in the Status field.

4.     Expand the IP section.

a.     Enter 192.0.2.2 in the IPv4 Address column of the IP Address field.

b.     Enter 255.255.255.0 in the Netmask column of the IP Address field.

c.     Click Add.

5.     Click Update.

Configure a Default Route

To configure a default route:

1.     Navigate to Network >> Interfaces >> Transparent.

2.     Enter 0.0.0.0 in the IP Address and IP Mask fields.

3.     Enter 192.0.2.1 in the Default Gateway field.

4.     Click Configure.

Use the CLI to Configure DSR in Route Mode

The following configuration procedures differ from the instructions provided in Use the CLI to Configure DSR in Transparent Mode:

The following commands enable the Ethernet interface used in the example and configure an IP address on it:

ACOS(config)# interface ethernet 3

ACOS(config-if:ethernet:3)# enable

ACOS(config-if:ethernet:3)# ip address 192.0.2.2 /24

ACOS(config-if:ethernet:3)# exit

 

The following command configures the default route through 192.0.2.1:

ACOS(config)# ip route 0.0.0.0 /0 192.0.2.1

 

Direct Server Return in Mixed Layer 2/Layer 3 Environment

You can configure the ACOS device to use some servers as backups in a DSR deployment. The backup servers are not required to be connected to the ACOS device at Layer 2 or in the same IP subnet. Figure 35 shows an example that uses a backup server in a different subnet.

NOTE:                               The deployment described in this section is useful for deploying backup servers to use only if primary servers are unavailable.

FIGURE 35         Backup Server in DSR Configuration

deploy_dsr_backup_server.png

 

In this example, two real servers are used as the primary servers for VIP 10.10.10.99:80. They are in the same IP subnet as the ACOS device. Each of them is configured for DSR: destination NAT is disabled on the virtual port.

Another server, 192.168.2.10, is configured as a backup, to be used only if both primary servers are unavailable. Since the backup server is a valuable network resource, serving as a server farm backup is only one of its functions. It also used by other applications elsewhere in the network. the ACOS device can be configured to use the server as a backup to a DSR server farm, without changing the network topology.

To deploy the backup server:

     In the service group, assign a higher priority to the members for the primary servers, so that the member for the backup server has the lower priority. By default, the ACOS device will not use the lower-priority server (the backup server) unless all the primary servers are down. Use the same priority for all the primary servers.

     Enable destination NAT on the backup server. By default, destination NAT is unset on real ports, and is set by the vir­tual port. Normally, destination NAT is disabled on virtual ports used for DSR. However, destination NAT needs to be enabled on the real port on the backup server.

Enabling destination NAT for the backup server allows the server to remain on a different subnet from the ACOS device, and still be used for the VIP that normally is served by DSR. The backup server does not need to be moved to a Layer 2 connection to the ACOS device and the server’s IP address does not need to be changed. It can remain on a different subnet from the ACOS device and the primary servers.

Destination NAT can not be set directly on an individual real port. To enable destination NAT on a real port, create a real port template and enable destination NAT in the template. You can bind the template to the real port itself, or to the service group member for the port.

     If you bind the template to the port itself, the template applies to the port in all service groups that use the port.

     If you bind the template to the service group member instead, the template applies to the port only within the ser­vice group. The template does not apply to the same port when used in other service groups.

Using the GUI

This section provides GUI configuration instructions.

Configure a Port Template to Enable Destination NAT on the Backup Server’s Port

1.     Navigate to ADC >> Templates >> SLB.

2.     Click Create and select Port from the drop-down list.

3.     Enter a name for the template in the Name field.

4.     To enable destination NAT, click the checkbox in the Destination NAT field.

5.     Click Create.

Configure the Service Group

1.     Navigate to ADC >> SLB >> Service Groups.

2.     Click Create to add a new service group.

3.     Enter the service group name.

4.     Add the primary servers to the service group:

a.     In the Member area of the window, click Create. The Create Member window appears.

b.     Select a primary server from the Server drop-down list.

c.     Enter the protocol port number in the Port field.

d.     Enter 16 in the Priority field.

e.     Click Create.

f.       Repeat for the other primary server.

5.     Add the backup server to the service group:

a.     In the Member area of the service group window, click Create.

b.     Select the backup server from the Server drop-down list.

c.     Enter the protocol port number in the Port field.

d.     Enter 1 in the Priority field.

e.     Select the port template for the backup server from the Server Port Template drop-down list. This is the template configured earlier.

f.       Click Create.

6.     Click Update.

 

To set the priority values of the primary servers to a higher value than the backup server, re-add the members for the primary servers’ ports, and use the priority option. Set the priority to a value higher than 1 (the default). Use the same priority value on each of the primary server’s member ports.

To enable destination NAT on a service port within a service group, use the dest-nat option in a server port template, then bind that template to the server port in the service group.

CLI Example

The following commands configure a server port template for the backup server:

ACOS(config)# slb template port dsrbackup

ACOS(config-rport)# dest-nat

ACOS(config-rport)# exit

The following commands add the members to the service group:

ACOS(config)# slb service-group sg-dsr tcp

ACOS(config-slb svc group)# member primarys1 80 priority 16

ACOS(config-slb svc group-member:80)# member primarys2 80 priority 16

ACOS(config-slb svc group-member:80)# member secondarys1 80 template port dsrbackup

 

Layer 3 Direct Server Return (IP Tunneling)

ACOS release supports IP-in-IP Tunneling. You can use this capability to deploy Layer 3 Direct Server Return (L3 DSR).

NOTE:                               When configuring DSR, the real server members in the Service Group must be listening on the same port. Port translation is not supported in Direct Server Return topologies.

This section contains the following topics:

     Overview of Layer 3 DSR

     Layer 3 DSR Configuration Example

 

Overview of Layer 3 DSR

When DSR is enabled, the ACOS device sends client requests to back-end servers in an IP-in-IP tunnel. These servers respond directly to the clients, bypassing the ACOS device on their return.* The packets from the real servers must appear as though they are actually coming from the ACOS VIP and not from the real servers. Using IP-in-IP Tunneling helps make this happen.

Methods to Display the ACOS VIP as the Source Address

In previous releases, the ACOS device supports L3 DSR by using the Differentiated Services Code Point (DSCP) field. This field is not used to support QoS (as per its original intention), but it is instead used to create a mapping between the DSCP value and the many VIPs on the ACOS device. This information is then stored in a table on the real server, and the server uses the table as a reference when it needs to know which VIP to include as the Source Address in the packet it sends back to the cli­ent.

Using the DSCP value to encode VIP-mappings may not work in all network environments. For example, the feature is not supported on Windows-based servers.

This release introduces a new mechanism that can be used to get the VIP to appear as the Source Address in the packet that the real server sends back to the client. This new approach is called IP-in-IP Tunneling, and it provides a helpful alternative for L3 DSR deployments in which DSCP is not supported.

IP-in-IP Tunneling for L3 DSR Routing

IP-in-IP Tunneling, or just “IP tunneling”, is commonly used to connect networks that use incompatible protocols. When traffic from a source network arrives at a network that uses an incompatible protocol (such as IPv4 and IPv6), the IP tunneling pro­tocol can be used to add an outer header to the original packet, thus encapsulating the original packet in another packet.

Through this process of encapsulating the original packet, traffic can be reliably carried from the source network, across a dis­similar transit network, and back to a network that uses the same protocol as the source network. When the packet reaches the far side of the IP tunnel, the outer header is stripped off (decapsulated), and the original packet arrives intact.

When IP Tunneling for L3 DSR is enabled on the ACOS device, an extra IP header is added to the client packet before it is for­warded over the IP tunnel to a real server. These real servers are configured to strip off the extra layer of IP encapsulation, yielding the original packet that was sent by the client. This packet is intact and otherwise unaffected by the encapsulation process.

By removing the outer header, the real server now has a packet with the source address of the client and the destination address of the ACOS VIP. (This would not have been true if the ACOS device had used standard Source NAT and Destination NAT to process the packet.) When the real server responds to the client, it crafts its response based upon a “pristine” packet that has not had its source and destination addresses modified by the NAT process.

When the real server responds to the client, the source and destination addresses are reversed (as per normal behavior):

     The packet’s source address (which was originally the client’s IP) is changed to become the ACOS VIP.

     The packet’s destination address (which was originally the ACOS VIP) is changed to become the client’s IP.

Details:

     Both IPv4 and IPv6 IP in IP are supported.

     Whereas using the DSCP value was only supported on Linux servers, IP tunneling for L3 DSR can be set up on most popular brands of web servers, such as Linux, Unix, or Windows.

     IP tunneling must be configured on each real server for which IP Tunneling for L3 DSR is enabled. Further, each real server must be configured to decapsulate the packets it receives and send those packets to the client that originated the request.

     In Direct Server Return (DSR) configurations, member servers in a Service Group must be listening on the same port. Port translation is not supported in DSR topologies.

     For more information about IP in IP (or "ipencap"), refer to RFC 2003.

FIGURE 33    shows an example of an ACOS device deployed in an L3 Direct Server Return (DSR) configuration. In DSR configu­rations, replies from real servers do not pass through the ACOS device but instead return directly to the client.

FIGURE 36         ACOS Deployment Example – IP Tunneling for DSR

deploy_dsr_ip_tunneling.png

 

In this example, the ACOS device is attached to the network in a “one-armed” configuration, through an Ethernet port or a trunk. (Our configuration sample shown later in this section uses Ethernet port 3.)

The blue arrows show the traffic flow for the traffic from the client at 3.3.3.50 and the real server at 7.7.7.50. Client requests go to the virtual server IP address at 4.4.4.118 (port 80). The ACOS device encapsulates the packets in an IP Tunnel and then for­wards them to real server. The real server de-capsulates the traffic and processes the client’s original packet. However, instead of sending the traffic back to the ACOS device, the real server sends the traffic directly to the client, bypassing the ACOS device.

DSR Health Checking

It is recommended that you configure Layer 3 or Layer 4-7 health checks, both of which are supported in DSR configurations.

NOTE:                               When using DSR health checking, a separate service group is required for each individ­ual virtual server.

Layer 3 DSR Health Checks

The target of the Layer 3 health checks can be the real IP addresses of the servers, or the virtual IP address, depending on your preference.

     To send the Layer 3 health checks to the real server IP addresses, you can use the default Layer 3 health method (ICMP).

     To send the Layer 3 health checks to the virtual IP address instead:

     Configure an ICMP health method with the transparent option enabled, and with the alias address set to the virtual IP address.

     Globally enable DSR health checking.

Layer 4-7 DSR Health Checking

Layer 4-7 health checks are sent to the same IP address as the Layer 3 health checks, and then addressed to the specific pro­tocol port. You can use the default TCP and UDP health monitors or configure new health monitors. This example uses the default TCP health monitor.

When IP tunneling is enabled, health check packets sent to the server are also encapsulated when sent through the IP tun­nel.

Requirements

This IP-in-IP Tunneling for L3 DSR configuration has certain requirements:

     Requirements on the ACOS device:

     In order to preserve the original client IP address, (which will be used as the destination address for packets sent from the real server to the client), make sure not to enable Source NAT under the virtual port where the ipinip com­mand is used.

NOTE:                               In the current release, L3 DSR is supported on the following virtual port types (service types): TCP, UDP, FTP, TFTP, and RTSP for both IPv4 and IPv6 protocols.

     Requirements on the real server:

     A loopback interface must be configured with the virtual server IP address. (If this does not work on your real server, it may be helpful to configure the real server end of the IP Tunnel with the ACOS VIP address.)

     ARP replies from the loopback interfaces must be disabled. (This applies to the loopback interfaces that have the virtual server IP address.)

     The real server must be configured with an IP Tunnel, and it must be configured to decapsulate traffic received from the ACOS device over that tunnel.

Layer 3 DSR Configuration Example

This section shows how to implement the configuration shown in Figure 33.

Using the CLI

The following commands enable an Ethernet interface on the ACOS device:

ACOS(config)# interface ethernet 3

ACOS(config-if:ethernet:3)# ip address 6.6.6.2 /24

ACOS(config-if:ethernet:3)# enable 

ACOS(config-if:ethernet:3)# exit 

 

Configure the Health Checks

ACOS(config)# health monitor hm-http

ACOS(config-health:monitor)# method http

ACOS(config-health:monitor)# exit

 

Globally Enable DSR Health Checking of VIPs

ACOS(config)# slb common

ACOS(config-common)# dsr-health-check-enable

ACOS(config-common)# exit 

 

Configure the Real Server(s)

ACOS(config)# slb server rs1 7.7.7.50

ACOS(config-real server)# port 80 tcp

ACOS(config-real server-node port)# exit

ACOS(config-real server)# exit

 

Configure the Service Group

For this configuration, the health monitor must be configured at the service group configuration level. If you try to apply the health monitor at the server port configuration level, the port may not come up.

ACOS(config)# slb service-group sg1 tcp

ACOS(config-slb svc group)# member rs1 80

ACOS(config-slb svc group-member:80)# health-check hm-http

ACOS(config-slb svc group-member:80)# exit

 

Configure the Virtual Server with ‘ipinip’ Option

ACOS(config)# slb virtual-server vipipinip 4.4.4.118

ACOS(config-slb vserver)# port 80 tcp

ACOS(config-slb vserver-vport)# service-group sg1

ACOS(config-slb vserver-vport)# ipinip 

ACOS(config-slb vserver-vport)# exit 

 

Configuration on the Real Servers

For the IP-in-IP Tunneling for L3 DSR feature to work correctly, the following configurations must be performed on each real server that will be process traffic from the IP tunnel:

     Configure a VIP on the real server and disable ARP for it. This VIP is typically configured as a loopback interface.

     Configure an IP-in-IP tunnel on each real server.

NOTE:                               When properly configured, the real server will decapsulate packets received from the IP tunnel, process the request in the client’s original packet, and send the response directly back to the client, bypassing the ACOS device.

 

*.   With L2 DSR, the ACOS device must be on the same subnet as the real servers. With L3 DSR, the ACOS device and real servers can be separated by a router.

Table of Contents

Index

Glossary

-Search-

Back