Table of Contents

Creating a Basic LocalDirector Configuration
Configuration Examples

Default Configuration Settings
One Virtual Server and Multiple Real Servers
Multiple Virtual Servers and One Real Server
Multiple Virtual Servers and Multiple Real Servers
Buddy Virtual Setup
Requesting the Same Server for Multiple Connections
Cookie-Sticky Setup
Client-Assigned Load Balancing
Secure Services
Port-Bound Servers
Maximum Connections and Weighted Configuration
Backup Configurations
Configuring with the data Command
Configuring UDP Traffic
Configuring LocalDirector for the MNLB Environment

Configuring LocalDirector as Service Manager

Configuring Accelerated Server Load Balancing

ASLB Packet Flow

Configuring LocalDirector

This chapter describes how to complete a basic configuration for LocalDirector. Topics include:

• Creating a Basic LocalDirector Configuration

• Configuration Examples

Creating a Basic LocalDirector Configuration

This section describes how to complete a basic configuration for LocalDirector and the server farm.

Basic configuration for LocalDirector includes setting its IP address, testing a connection to the network, and setting a password. Configuration for the server farm includes defining virtual servers and real servers, setting the load-balancing and redirection options, binding virtual servers and real servers, and putting all servers into service. Once basic configuration is complete, see the "Configuration Examples" section for additional procedures that can be used to set up specific LocalDirector features for your site.

To configure LocalDirector system settings (basic configuration), perform the following steps:

Step 2   Power on LocalDirector.

Note   Because LocalDirector ships with its software loaded in Flash memory, LocalDirector boots without a system disk.

As LocalDirector boots, messages such as the following appear:

Note   The messages displayed at bootup differ depending on the LocalDirector platform and the number and type of interfaces installed.

Step 3   Use the enable command to access privileged mode.

Step 4   Use the configuration command to access LocalDirector configuration commands.

Step 5   Use the ip address command to assign the LocalDirector IP address and subnet mask.

Step 6   Use the ping command to determine if LocalDirector is connected or if a host is available on the network. If this test fails, follow these steps:

   a. Make sure that you have defined an IP address for LocalDirector, and that it is a valid network address.

   b. Create a virtual address and use the ping-allow command to allow you to ping the virtual server. You can also use the traceroute command with virtual IP addresses, but you cannot use traceroute with the LocalDirector IP address.

   c. Ping real servers on the LocalDirector network.

   d. Test each side of the connection by pinging hosts on each network segment. Check all cable connections and ensure they are secure.

Step 7   Use the enable password command to change the privileged mode password.

Step 8   If preferred, use the hostname command to change the host name for the LocalDirector command-line prompt. Note that in a failover configuration, both units have the same host name because the configuration is copied from one unit to the other.

To configure the LocalDirector server farm (secondary configuration), perform the following steps:

Step 2   If preferred, use the redirection command to change the default directed mode (Network Address Translation) to dispatched mode for the virtual servers. Additionally, use the alias ip address command to specify the virtual IP address on each real server that uses dispatched mode.

Step 3   Use the predictor command to set the type of load balancing for each virtual server.

Step 4   Use the real command to define real servers.

Step 5   Use the bind command to associate each virtual server to a real server.

Step 6   Use the in-service command to designate real servers and virtual servers as in service. (This can also be done when the virtual servers and real servers are defined.)

Step 7   Use the write terminal, show real, show virtual, and show bind commands to check the configuration.

Step 8   Use the write memory command to store the configuration in Flash memory.

Step 9   Use the show config command to verify the configuration stored in Flash memory.

The basic configuration is complete.

Step 10   Enter Ctrl-Z to exit the configuration mode. Use the disable command to exit privileged mode.

Figure 3-1 shows an example of a basic configuration with one virtual server bound to two real servers.

Configuration Examples

To help determine virtual and real server configurations, diagram the implementation before you begin. Ensure that any virtual IP address you configure is from a valid IP network. If the virtual address is to be accessed from the Internet, the IP address must be part of a Network Information Center-allocated network number.

This section provides server configuration examples in the following sections:

• Default Configuration Settings

• One Virtual Server and Multiple Real Servers

• Multiple Virtual Servers and One Real Server

• Multiple Virtual Servers and Multiple Real Servers

• Buddy Virtual Setup

• Requesting the Same Server for Multiple Connections

• Cookie-Sticky Setup

• Client-Assigned Load Balancing

• Secure Services

• Port-Bound Servers

• Maximum Connections and Weighted Configuration

• Backup Configurations

• Configuring with the data Command

• Configuring UDP Traffic

• Configuring LocalDirector for the MNLB Environment

• Configuring Accelerated Server Load Balancing

Default Configuration Settings

One Virtual Server and Multiple Real Servers

In this example, LocalDirector is load balancing all TCP traffic over two servers to provide Web services. Figure 3-2 shows the network configuration.

Step 2   Use the configuration t command to enter configuration mode:

Step 3   Use the ip address command to specify LocalDirector IP address 192.168.1.89, and subnet mask 255.255.255.0:

Step 4   Use the interface ethernet command with the auto option (if your interface card supports this option) to automatically set the speed of the Ethernet interface:

Otherwise, to set the speed manually, use the interface ethernet command with the option that is appropriate for your card:

Note   The four-port RNS adapter cards cannot use the auto option. These cards display the following string in the show interface command output: rns23x0

Step 5   Use the shutdown command to disable unused interface ports:

Step 6   Use the name command to identify IP address 192.168.1.99 as domain, and the virtual command to define domain as a virtual server:

Step 7   Use the name command to identify IP address 192.168.1.1 as server 1 and 192.168.1.2 as server 2:

Step 8   Use the real command to identify server 1 and server 2 as real servers, and the is (in-service) option to enable the real servers to start accepting connections:

Step 9   Use the bind command to associate domain with server 1 and server 2 and establish the load-balancing relationship between the virtual and the real servers:

Step 10   Use the is command to bring the virtual server into service:

Step 11   Use the write terminal command to view the running configuration before it is saved.

Step 12   Use the write mem command to save the new settings:

Step 13   View the saved configuration with the show configuration command:

Multiple Virtual Servers and One Real Server

In this example, four virtual addresses are bound to a single Web server, as shown in Figure 3-3, allowing you to provide multiple DNS entries for one server. In other words, one real server supports multiple domain names. Virtual IP addresses 192.168.1.99, 192.168.1.100, 192.168.1.101, and 192.168.1.102 are identified as domain 1, domain 2, domain 3, and domain 4, respectively. Port 80 traffic for each virtual IP address is bound to different ports on real server IP address 192.168.1.2.

All Web traffic destined for domain 1 accesses information on real server 192.168.1.2 through port 8000. Traffic destined for domain 2 accesses information on real server 192.168.1.2 through port 8001, and so on.

Multiple Virtual Servers and Multiple Real Servers

You can combine multiple virtual servers and multiple real servers so that each virtual server sends network traffic to the same port across real servers, as shown in Figure 3-4. All TCP traffic destined for virtual server 192.168.1.100 is load balanced across the three real servers on port 8001. Traffic destined for virtual server 192.168.1.101 is load balanced across the real servers on port 8002.

A combination of virtual servers and real servers can also be used to load balance traffic across server clusters, as shown in Figure 3-5.

Each virtual server can have a different load-balancing option set with the predictor command. For example, 192.168.1.100 can be configured to use the leastconns option, and 192.168.1.101 can be configured to use the weighted option.

In Figure 3-5, TCP connections to domain 1 are load balanced across Server Cluster A containing real servers 192.168.1.1, 192.168.1.2, and 192.168.1.3. Connections to domain 2 are load balanced across Server Cluster B containing real servers 192.168.1.4, 192.168.1.5, and 192.168.1.6.

Buddy Virtual Setup

Use the buddy command to create a buddy group (in the following procedure, my_app) consisting of a list of virtual servers. Certain commands and parameters that affect one virtual server affect all other virtual servers in the buddy group (for example, to share the generic information from the sticky command). A virtual server can reside in only one buddy group; if it currently exists in a group, it must be removed from that group before it can be added to a new group. An unlimited number of virtual servers can exist within a buddy group.

Step 2   Display the contents of the group with the show buddy command.

With this setup, when the sticky command is used for virtual server 10.0.0.200 and then a client visits the virtual server 10.0.0.100 after visiting 10.0.0.200, that client will be sent to the same real server as on the 10.0.0.100 connection.

Requesting the Same Server for Multiple Connections

The sticky command ensures that the same client gets the same real server for multiple connections. The sticky command allows you to get back to the same real server and retain the statefulness of the client/server connection. For example, if a client is completing an online form, the sticky command ensures that multiple connections are sent to the same server to complete the transaction. If this command is not used, each connection attempt to a virtual server is routed according to the predictor option in effect for that virtual server, without regard to prior history of the foreign host.

The sticky command does not time the length of a client connection; it times periods of inactivity. For example, if the sticky command is set to 5, and the client is active, new requests from the client are not sent to another server through load balancing, even if more than 5 minutes have elapsed. However, if 5 minutes of connection inactivity have elapsed, the requests from the client can be sent to another real server.

For Secure Socket Layer (SSL) connections, use the ssl option of the sticky command. LocalDirector performs a proxy connection until an SSL session ID is obtained from the HTTP headers. If there is already a sticky association in the LocalDirector cache, the host or server for that association is used. If there is no sticky association, a real server is selected, and a sticky association is created.

---

Note   If you have a proxy server in front of LocalDirector, the sticky command cannot work because all clients will appear to have the same source IP address. We recommend that you put LocalDirector in front of the proxy server. Use port-bound virtual servers to create less imbalance.

---

---

Note   If you have a proxy server in front of LocalDirector, use the ssl option of the sticky command to use the session ID as the connection identifier instead of the default generic option, which uses the source IP address.

---

To configure a stateful client/server connection using SSL, perform the following steps:

---

Step 1   Use the virtual command to identify 192.168.1.1 as a virtual server accepting traffic on port 80 (HTTP) and port 443 (SSL):

ld(config)# virtual 192.168.1.1:80 ld(config)# virtual 192.168.1.1:443

Step 2   Use the real command to identify 192.168.1.220 and 192.168.1.221 as real servers accepting traffic on port 80 (HTTP) and port 443 (SSL):

ld(config)# real 192.168.1.220:80 is ld(config)# real 192.168.1.221:80 is ld(config)# real 192.168.1.220:443 is ld(config)# real 192.168.1.221:443 is

Step 3   Use the bind command to bind the virtual servers accepting traffic on port 80 to the real servers accepting traffic on port 80:

ld(config)# bind 192.168.1.1:80 192.168.1.220:80 192.168.1.221:80

Step 4   Use the bind command to bind the virtual servers accepting traffic on port 443 to the real servers accepting traffic on port 443:

ld(config) bind 192.168.1.1:443 192.168.1.220:443 192.168.1.221:443

Step 5   Use the sticky command to ensure that requests to virtual server 192.168.1.1:443 are sent to the same real server until 10 minutes of inactivity elapse:

ld(config)# sticky 192.168.1.1:443:0:tcp 10 ssl

Step 6   Use the is command to put the virtual servers in service:

ld(config)# is virtual 192.168.1.1:80:0:tcp ld(config)# is virtual 192.168.1.1:443:0:tcp

Step 7   Use the show bind command to display server bind associations:

ld(config)# show bind Virtual Real 192.168.1.1:443:0:tcp (IS) 192.168.1.221:443:tcp (IS) 192.168.1.220:443:tcp (IS) 192.168.1.1:80:0:tcp (IS) 192.168.1.221:80:tcp (IS) 192.168.1.220:80:tcp (IS)

Step 8   Use the show sticky command to display the sticky command setting:

ld(config)# show sticky Machine Sticky 192.168.1.1:443:0:tcp 10 ssl

Step 9   Use the show configuration command to view the entire configuration:

ld(config)# show configuration : Saved : LocalDirector 420 Version 3.1.0.106 syslog output 20.3 no syslog console enable password dfeaf10390e560aea745ccba53e044 encrypted hostname localdirector no shutdown ethernet 0 no shutdown ethernet 1 shutdown ethernet 2 shutdown ethernet 3 interface ethernet 0 100basetx interface ethernet 1 100basetx interface ethernet 2 100basetx interface ethernet 3 100basetx mtu 0 1500 mtu 1 1500 mtu 2 1500 mtu 3 1500 multiring all no secure 0 no secure 1 no secure 2 no secure 3 ping-allow 0 ping-allow 1 ping-allow 2 ping-allow 3 no rip passive failover ip address 0.0.0.0 no failover password cisco no snmp-server contact no snmp-server location casa service-manager port 1638 virtual 192.168.1.1:443:0:tcp is virtual 192.168.1.1:80:0:tcp is real 192.168.1.221:443:0:tcp is real 192.168.1.220:443:0:tcp is real 192.168.1.221:80:0:tcp is real 192.168.1.220:80:0:tcp is bind 192.168.1.1:443:0:tcp 192.168.1.220:443:0:tcp bind 192.168.1.1:80:0:tcp 192.168.1.221:80:0:tcp bind 192.168.1.1:80:0:tcp 192.168.1.220:80:0:tcp sticky 192.168.1.1:443:0:tcp 10 ssl

---

Cookie-Sticky Setup

The cookie-insert option is a sticky connection based on a cookie created by LocalDirector. LocalDirector receives (acting as a proxy server) new client connections and scans the HTTP GET request for a cookie.

• If a cookie is not detected, LocalDirector assigns the connection to a real server and creates the cookie.

• If a cookie is detected, LocalDirector extracts it to determine the sticky real server ID and the expiration time. If the time has not expired, LocalDirector forwards the connection to the sticky real server. If the time has expired, LocalDirector assigns the connection to a new sticky real server and creates a new cookie.

The cookie-passive option is a sticky connection based on a cookie created by the sticky real server. LocalDirector learns the cookie and stores it in memory. LocalDirector receives (acting as a proxy server) new client connections and scans the HTTP GET request for a cookie that matches one in memory.

Note   Make sure the LocalDirector clock and the clock of the client and server are set correctly for proper operation.

• If there is a match and the time has not expired, LocalDirector forwards packets to the previously selected sticky real server. LocalDirector then scans packets from the sticky real server until the first HTTP response is detected.

• If there is a match but the time has expired, LocalDirector assigns the connection to a new real server. If there is no set-cookie token in the HTTP response, LocalDirector stops acting as the proxy server for the connection and forwards all packets directly to the sticky real server.

If there is a set-cookie token in the HTTP response, LocalDirector stores the new cookie in memory before it stops acting as a proxy server for the connection.

If the sticky real server does not answer or returns a TCP RST, LocalDirector assigns the connection to a new real server. Refer to the network environment shown in Figure 3-6 for this setup example.

To configure the cookie-sticky setup, perform the following steps:

---

Step 1   Change the date and time on the primary LocalDirector. You must use Coordinated Universal Time (UTC).

ld(config)# clock set 18:01:00 jan 18 2000

Step 2   Create two real server IP addresses, one for Web server NT3 and one for Web server NT4.

Step 3   Set a virtual server IP address on LocalDirector and set the virtual server to an in-service state.

Step 4   Set the load-balancing predictor to the round-robin method.

ld(config)# predictor virtual_id roundrobin

Step 5   Set the cookie-insert mode on LocalDirector (in this example, you must set the minutes value, which appears as 4 minutes).

ld(config)# sticky virtual_id 04 cookie-insert cookie-name

---

---

Note   With the cookie-insert option, LocalDirector generates the cookie to the client. With the cookie-passive option, the server generates the cookie to the client. LocalDirector learns and stores the cookie, and passes it to the client. LocalDirector makes an association based on the cookie name.

---

Client-Assigned Load Balancing

Use the assign command to associate real servers to the bind-ids of virtual servers and direct client requests to a specific instance of a virtual server, as shown in Figure 3-7. Depending on the bindings of virtual servers to real servers, different real machines are used for different clients.

In this example, clients from 172.31.17.0 are directed through the virtual server with a bind-id of 1 to the real servers with IP addresses 10.10.20.1, 10.10.20.2, and 10.10.20.3. Client requests from 192.150.50.0 go through the virtual server with a bind-id of 2 to real servers with IP addresses 10.10.30.1 and 10.10.30.2. Requests from any other source IP address go to the virtual server with the default bind-id of 0, and that virtual server is bound to real servers 10.10.10.1, 10.10.10.2, and 10.10.10.3.

Secure Services

The example shown in Figure 3-8 uses LocalDirector security features of SecureAccess, SecureBind, and SecureBridge to secure a network both internally and externally.

In this example, the company has a Class C network with an IP address of 192.168.1.0. The virtual address in DNS is 192.168.1.8 for www.domain.com. Requests from internal clients are directed to different real servers. The IP address of the system administrator is 192.168.1.101.

Port-Bound Servers

Both TCP and UDP services can be directed to specific servers. Figure 3-9 shows how to send HTTP traffic to server A, send Telnet traffic to server B, and direct all other traffic to servers C and D. Three virtual servers have IP address 192.168.1.100; one accepts only HTTP traffic (port 80), one accepts Telnet traffic (port 23), and the other accepts all other connections (default).

Note   If you do not specify a port when defining a server, the port is listed as the default. The default port for a server accepts all network connections, except for those directed to a specific port by using the port binding feature.

Names can also be used to refer to the real and virtual servers in this example.

Maximum Connections and Weighted Configuration

The maxconns command allows you to specify the maximum number of connections that each real server can have at one time. A server administrator can set the maximum connections to a level that avoids exceeding the capacity threshold of the server. Often, server administrators have a good idea of the load that a server can bear, and the maxconns command can be used to prevent a server from failing because of capacity overload. Clients requesting connections to a server farm with no available connections receive a timeout message.

A higher percentage of connections can be directed to servers that offer increased performance by selecting the weighted option of the predictor command and setting values with the weight command.

Figure 3-10 shows four servers with varying performance indices, maximum connections settings, and weight values. In this example, a weight of 2 is assigned to the low-end server, sending 13 percent of the connections to that server. This particular server cannot accept more than 500 simultaneous connections, so maxconns is set to 500. The same reasoning applies to the midrange server and the two
high-end servers.

Step 6   Use the predictor command to set load balancing with the weighted option:

Step 7   Use the weight command to assign weight values to each of the real servers:

Step 8   Use the maxconns command to limit the number of connections that each real server can accept:

Step 9   Use the show bind command to display the association between the virtual and real servers:

Step 10   Use the show weight command to display the weight values assigned to the real servers:

Backup Configurations

To ensure that TCP services continue to run if a server has failed or is out of service, you can identify an alternative destination for server traffic by specifying a backup. The term "backup" is used to define a hot-standby for a real or virtual server defined on LocalDirector. The backup can be a virtual or real server; thus, it is possible to use the backup command in any combination.

For real servers, a backup is used if the real server has failed or is out of service. For a virtual server, a backup is used if all real servers (and their backups) bound to the virtual server have failed or are out of service. If the virtual server itself is out of service, a TCP RST is sent to the client requesting the connection.

Note   A server cannot be used as a backup for itself. For example, a real server cannot serve as a backup for a virtual server to which it is bound. If this configuration is attempted, an error message is generated.

When the server being backed up returns to service, connections are no longer directed to the backup server and they are sent according to the LocalDirector configuration.

You can back up real servers with virtual addresses, and you can back up virtual servers with a real server. You can use a backup server when the real or virtual server is not in service (for example, it has failed or is out of service).

Note   If the backup server itself is not available, LocalDirector does not check the backup of the backup server. The backup feature checks only one level.

The following example shows a virtual server backing up another virtual server. If real servers 10.1.1.1 and 10.1.1.2 fail (thus failing virtual server 10.10.10.10), the real servers bound to virtual server 10.10.10.20 are used instead.

In the following example, real server 10.1.1.3 is backing up the two real servers bound to virtual server 10.10.10.10:

The same result can be achieved with the following configuration, in which real server 10.1.1.3 backs up the two real servers directly, instead of backing up the virtual server:

Configuring with the data Command

Some Web servers (such as Microsoft Windows NT 4.0) continue to establish connections to a real server even though the application daemon is not functioning. Use the data command to limit the number of connections sent to a server that is not sending data.

LocalDirector tracks connections and can detect when clients are requesting data and the server is not responding with data. If the DataIn Conns value of a server exceeds the defined threshold and all other real servers bound to the virtual server are at less than 80 percent of their DataIn capacity, the server is failed. Display the DataIn Conns value with the show real command.

Configuring UDP Traffic

This section describes how to set up UDP traffic on the virtual servers and real servers, and a mix of TCP and UDP traffic on the virtual servers and real servers.

Configuration for UDP is similar to TCP, except the udp protocol option is used instead of the tcp option in the virtual_id and real_id server parameters. Additionally, because UDP is a connectionless protocol, the connection is kept alive through use of a timer.

The connection duration timer starts on the first packet of the flow that is received on the virtual server. Set the timer with the timeout command, as shown in the following example. Connections remain valid until the timer times out because of inactivity on the connection flow.

To set up a UDP configuration for a virtual server and a real server, perform the following steps:

Step 2   Use the timeout command to set the connection duration period on the virtual server to 11 minutes.

Step 3   Use the real command to identify 192.10.10.1:300:0 as a real server running UDP through port 300. Use the is option to put the server in service.

Step 4   Use the bind command to associate the virtual server to the real server:

When an application can use a known connection port, the buddy command can be used to group the connections, ensuring that activity on one stream updates timers on all streams.

To set up a buddy group that contains TCP and UDP virtual servers representing TCP and UDP real servers, perform the following steps:

Step 2   Use the buddy command to create the buddy group tcp-udp and add the TCP and UDP virtual servers to it:

Step 3   Use the real command to identify three real servers running both TCP and UDP. Use the is option to put the servers in service.

Step 4   Use the bind command to associate the virtual servers to the real servers. Notice the TCP virtual servers are bound to the TCP real servers.

Configuring LocalDirector for the MNLB Environment

An overview of the Multi-Node Load Balancing (MNLB) environment and descriptions of how to configure and use the components of the Network Director environment can be found in the MNLB User Guide.

Configuring LocalDirector as Service Manager

When LocalDirector is the Service Manager, it determines a real server for each new packet that arrives, based on the type of load balancing that is configured. LocalDirector notifies the Forwarding Agents of that decision over the multicast UDP port. The Forwarding Agents then direct all subsequent packets of that packet stream to the real server that was chosen.

To configure LocalDirector as a Service Manager, perform the following steps:

Step 2   You can use the casa service-manager multicast-ttl command to change the Service Manager multicast connection Time To Live value. The default is 3 hops:

Step 3   Use the virtual command to define the virtual servers:

Step 4   Use the real command to define the real servers:

Step 5   Use the bind command to associate the virtual server 10.10.10.50:0:0:tcp with real server 10.10.10.221:0 and establish the load-balancing relationship between the virtual and the real servers:

Step 6   Use the bind command to associate the virtual server 10.10.10.50:23:0:tcp with real server 10.10.10.221:23 and establish the load-balancing relationship between the virtual and the real servers:

Step 7   Use the redirection command to configure CASA mode for the virtual servers:

Configuring Accelerated Server Load Balancing

Accelerated server load balancing (ASLB) requires two Ethernet links between LocalDirector and the Catalyst 6000 family switch. One link must be connected to the VLAN that the router is on (VLAN 10 in Figure 3-11). The other link must be connected to the VLAN that the real servers are on (VLAN 20 in Figure 3-11).

To set up ASLB according to the information in Figure 3-11, perform the following steps:

Step 2   Use the real command to identify the three servers:

Step 3   Use the bind command to associate the virtual server to the real servers:

Step 4   Use the predictor command to set load balancing with the roundrobin option:

Step 5   Use the redirection command to enable ASLB for the virtual server with the dispatch assisted option:

ASLB Packet Flow

When an inbound connection synchronization (TCP SYN) packet arrives with a destination MAC address of the LocalDirector virtual server in the Layer 3 header, the switch forwards the packet to LocalDirector at port P_A. (See Figure 3-11.) LocalDirector makes the load balancing decision, changes the destination MAC address to that of the real server, and forwards the packet to the switch at port P_B.

Note   LocalDirector inserts its own MAC address in the SYN packet before forwarding the packet to the switch. In standalone mode, LocalDirector always preserves original MAC addresses when forwarding packets to the switch.

The switch creates an inbound ASLB Multi-Layer Switching (MLS) entry in the Layer 3 forwarding tables as it forwards the packet to the real server. All subsequent packets that match the inbound ASLB MLS entry are Layer 3-switched (accelerated) to the real server, unless the packet is fragmented or contains a connection finish (TCP FIN) or connection reset (TCP RST).

When the outbound SYN packet from the real server arrives, the switch forwards the packet to LocalDirector at port P_B. LocalDirector changes the source MAC address to that of the LocalDirector virtual server and forwards the packet to the switch at port P_A.The switch creates an outbound ASLB MLS entry in the Layer 3 forwarding table as it forwards the packet to the router. All subsequent packets that match the outbound ASLB MLS entry are switched directly to the router, unless the packet is fragmented or contains a FIN or an RST.

Packets containing a FIN or an RST travel the same path as a SYN packet. The switch purges the inbound ASLB MLS entry when it forwards the FIN or RST packet to LocalDirector. The switch purges the outbound ASLB MLS entry as it forwards the FIN or RST packet to LocalDirector.

Note   LocalDirector must be in dispatch assisted mode for ASLB to work. Use the redirection command to set dispatch assisted mode.

Posted: Wed Jan 3 13:22:01 PST 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.