Configuring the WSM using Device Manager

Topology rules for SLB

Use the following guidelines when configuring SLB topologies.

In standard SLB, all client requests to a virtual server IP address and all responses from the real servers must pass through the WSM. If there is a path between the client and the real servers that does not pass through the WSM, the WSM can be configured to proxy requests in order to guarantee that responses use the correct path.

For more information, see Configuring proxy IP addresses.

Make sure that identical content is available to each server in the same pool by either duplicating static applications and data on each real server in the pool, or providing each real server in the pool with access to the same data through use of a shared file system or back-end database server.
Configure persistence (or use minimum misses or hash metrics) for connections that require a series of client requests go to the same real server to retain data between connections. These services include Web search results, multi-page forms that the user fills in, or custom Web-based applications typically created using cgi-bin scripts. For more information, see Maintaining session persistence.

Connect clients and servers through the same WSM port. Each WSM port can process client requests, server traffic, or both. You can enable or disable processing on a port independently for client or server traffic.

Layer 4 client processing	Ports configured to process client request traffic provide address translation from virtual server IP to real server IP address.
Layer 4 server processing	Ports configured to process server responses to client requests provide address translation from real server IP address to virtual server IP address. These ports require real servers to be connected to the WSM directly or through a hub, router, or another WSM.

Note: WSM ports configured for Layer 4 client/server processing can simultaneously provide Layer 2 switching and IP routing.