|
|
This chapter illustrates several of the configuration options available with LocalDirector. The commands to implements these configurations are described in "Installing and Configuring LocalDirector."
LocalDirector uses directed or dispatch mode to appear to the client as if it is communicating directly with a real server. If the client and server are on the same network segment, the response from the server bypasses LocalDirector, and the traffic will not be load balanced. All traffic must pass through LocalDirector and be directed to the real servers.
The following LocalDirector example network configurations are shown in this chapter:
LocalDirector serves as a transparent learning bridge to forward data packets between its interfaces. Because of its bridge capability, LocalDirector must not be installed on the network parallel to another bridge. Only use LocalDirector to connect to servers allowing a single way in or out to the network through LocalDirector, as shown in Figure 3-1.
If there is another path from the network to your servers, a bridge loop is created and LocalDirector does not work properly. LocalDirector automatically detects a bridge loop and tries to recover. SYSLOG messages are generated to indicate there is a bridge loop, and virtual and real servers have intermittent failures.
If the real servers have two single-attached interfaces (for example, they are dual-homed), make sure that load-balanced traffic cannot bypass LocalDirector. LocalDirector must be between the real servers and the Internet cloud that contains the clients. It must see all the packets coming from the clients to the virtual server and all the traffic that comes back in response to the client-to-virtual packets.
In addition, packets from the clients must come in on one interface and go out to the real servers on a different interface. If these rules are not followed, LocalDirector cannot perform load balancing.
Figure 3-2 shows a basic LocalDirector network implementation using hubs or switches.
Figure 3-3 shows a LocalDirector network with multiple server farms on different LocalDirector interfaces.
Figure 3-4 and Figure 3-5 show LocalDirector implementations that include routers.
Starting in LocalDirector Version 3.1, secure servers (those whose IP addresses are protected from the Internet) can be set up using software or hardware.
With software, set an internal subnet address as an aliased IP address on LocalDirector, using the alias ip address command. As shown in Figure 3-6, the alias IP address 10.10.10.253 allows connection with real servers in the 10.10.10.x subnet. Clients accessing the secure servers will see the LocalDirector virtual IP address, 192.168.1.100, as the server IP address.
When hardware is used to set up your secure servers, if you have a router on either side of LocalDirector, the LocalDirector IP address can be in a different subnet from the real servers, or you can place the real servers in multiple subnets on the inside of LocalDirector. Figure 3-7 shows real servers on a different subnet from LocalDirector.
If you do not use IP aliasing and you have only one router on the Internet side of LocalDirector with no router on the inside, LocalDirector sends all requests for the second subnet to its default gateway, the router. Because LocalDirector does not understand having two subnets (local, real servers, or real servers on multiple subnets), it uses its default gateway for the second subnet, which means you will see duplicate traffic on your
router-to-LocalDirector Ethernet segment.
To resolve this problem, place the local IP address of LocalDirector in the same subnet as the real servers, and then place the virtual IP address in a different subnet. The router must have the second subnet listed on its Ethernet as a secondary address, and the address must be Network Information Center (InterNIC) registered. The router then knows to route packets back toward LocalDirector, which acts as a bridge and just sends them through.
The following Cisco products support Fast EtherChannel:
The following Fast EtherChannel information is available online:
Follow this procedure to set up your Catalyst 5000 switch to support Fast EtherChannel:
Step 1 Assign a number to the VLAN (vlan_num) and identify the numbers of the ports on the module belonging to the VLAN.
Console> (enable) set vlan [vlan_num] [port_list]
Step 2 Disable spanning tree for that VLAN:
Console> (enable) set spantree disable [vlan_num]
Step 3 Assign the ports you want to use as a Fast EtherChannel. Do not use the auto keyword because LocalDirector Fast EtherChannel does not implement Port Aggregation Protocol (PAgP):
Console> (enable) set port channel [port_list] on
Step 4 Set the port speed to 100 and duplex to full. The LocalDirector 4-port card does not autonegotiate, and the LocalDirector channel command configures ports in the channel as 100full:
Console> (enable) set port speed [port_list] 100
Console> (enable) set port duplex [port_list] full
Follow this procedure to set up LocalDirector for Fast EtherChannel:
Step 1 Assign LocalDirector interfaces as part of a Fast EtherChannel with the channel command. Fast EtherChannel interfaces on LocalDirector must be on the same interface card. Specify the starting interface number and the number of interfaces you want in the channel, either two or four:
LocalDirector (config#) channel [interface_number] {two | four}
Step 2 Make sure the interface speed is 100 and duplex is set to full with the 100full option:
LocalDirector (config#) interface ethernet [interface_number] 100full
Figure 3-8 shows a LocalDirector Fast EtherChannel implementation.
Figure 3-9 shows a highly redundant, fault-tolerant configuration.
Figure 3-10 shows a LocalDirector network with a bridge loop that does not work.
Posted: Tue Feb 22 15:31:43 PST 2000
Copyright 1989 - 2000©Cisco Systems Inc.