eff: ex-3--cisco-localdirector

8/14/2019 EFF: Ex-3--Cisco-LocalDirector

http://slidepdf.com/reader/full/eff-ex-3-cisco-localdirector 1/52

1

Doc. No.

Cisco Systems, Inc.All rights reserved.

170 West Tasman DriveSan Jose, CA 95134-1706USA

Cisco Systems, Inc.Corporate Headquarters

Copyright © 1997

Cisco LocalDirector Version 1.6.3 Release Notes

October, 1997This document describes changes to features and commands that are different or not described in the

Cisco LocalDirector Installation and Configuration Guide (Document Number 78-3456-04).

The following sections are included:

• Changes for Version 1.6

• Feature Changes

• New or Changed Commands

• Cisco Connection Online

• CD-ROM Documentation

Changes for Version 1.6Cisco LocalDirector version 1.6 includes the following changes:

Bug Fixes in version 1.6.3

• TCP packets generated by LocalDirector had an incorrect TCP checksum, which caused the

station receiving a RST to ignore it. The LocalDirector now generates the correct checksum for

RST packets.

• LocalDirector now supports fragmented packets from real servers. Fragmented packets to virtual

servers have been supported since version 1.5.

• SNMP auto discovery no longer causes LocalDirector to crash.

• The FDDI interface option was broken in version 1.6.2, but is fixed in version 1.6.3.

• The no option for the sticky command was removed in version 1.6.2, but it is included in

version 1.6.3.

78-3880-05



2 Cisco LocalDirector Version 1.6.3 Release Notes

Changes for Version 1.6

Bug Fixes in version 1.6.2• The software labels on the LocalDirector interfaces were reversed, and now they are correct. The

interface numbers on back of the LocalDirector match the interface numbers in the software. This

will not affect use of the ping command, because the ping will be sent out of both interfaces now.

• The SNMP messages “LocalDirector booted” and “SNMP warmstart” are now sent.• In version 1.5, SNMP/SYSLOG messages could only be sent out the interface labeled 0. In

version 1.6, the SNMP/SYSLOG messages are sent out of both interfaces.

• In version 1.5, you could use Telnet to access the LocalDirector; however, you could only Telnet

to the active LocalDirector and only two Telnet sessions were supported per interface. In version

1.6, you can use Telnet to access the LocalDirector from any interface or any combination of

interface 0 and interface 1.

• LocalDirector correctly stores static ARPs in the configuration.

• In version 1.5, FTP control connections were timed out by the LocalDirector while the FTP data

connection was still active. In version 1.6, the LocalDirector will not “timeout” an FTP control

connection while the FTP data connection is still active.

• Static routes are no longer shown twice with the show route command.

• In version 1.5, broadcast packets sourced by the LocalDirector (for example, ARP requests) may

have an incorrect source MAC address. In version 1.6, all broadcasts from the LocalDirector will

have the correct source MAC address, which is the MAC address of the LocalDirector unit.

• If a maximum connection value is set on all of the real servers bound to a virtual server, the virtual

servers may be reported as failed. When all of the real servers have reached the value set with

the maxconns command, the virtual server will not be able to service new connections. When

the show virtual command is issued, it will show the state of the virtual server as FAILED, and

a SYSLOG message is generated. As soon as the real servers fall below the value set by

maxconns, the virtual server will automatically be brought back in-service.

Known Bugs

• Passive FTP connections are not handled correctly by LocalDirector. If a client initiates a

Passive FTP connection, then the real server will be accessed directly for an FTP data

connection. As long as routes are set up correctly on the real servers, this will not affect the FTP

client; however, FTP data connections will not be counted for that real server on the

LocalDirector.

Note The only time this could be a problem is if you use unregistered IP addresses on real

machines. The client cannot communicate directly with a real machine that has an unregistered IP

address across the Internet.

• For SNMP, the interface numbers on the SNMP host are different from the interface numbers on

the LocalDirector. For example:

snmp ifc 1 = LD ifc 0

snmp ifc 2 = LD ifc 1

• If SYSLOG messages are sent to the console while in configuration mode, the LocalDirector

could crash if a lot of SYSLOG messages are being generated. To avoid this, direct output to a

SYSLOG host instead. See syslog console and syslog host in the Cisco LocalDirector

Installation and Configuration Guide for more information.



Cisco LocalDirector Version 1.6.3 Release Notes 3

Feature Changes

Notes and Caveats

• The failover IP address and system IP address for LocalDirector must be on the same IP network.

Note A failover IP address must be set for failover to work properly. Failover changed significantly

in version 1.6, and failover must be re-configured when LocalDirector units are upgraded from aprevious version.

• The LocalDirector will not leave SynGuard mode once it is entered unless you turn SynGuard

off, or raise the number of unanswered SYNs allowed above the current level (which will force

it out of SynGuard mode).

• The map command will be removed in the next release of LocalDirector.

• The values assigned with the name command can be up to 32 alphanumeric characters. Names

that are longer than 32 characters will be truncated. The name command is optional, and it is not

related to DNS. It provides a means of making LocalDirector servers easier to configure, and the

names associated to the configuration do not have to be synchronized with DNS.

• In order to use any weights defined for a real server, the weighted predictor must be set. If

weights are assigned and the leastconns predictor is set, the weights will not have an affect on

load balancing.

• If you are upgrading from version 1.2.5, double check the interface and subnet mask of the

LocalDirector. If these values are different from the original configuration, use the interface and

ip address commands to change back to the previous settings.

Feature ChangesThe following sections describe changes to LocalDirector features.

FailoverFailover now works in a switched environment, and configuration replication between the

LocalDirector primary and standby unit is automatic. The LocalDirector will now auto-recover if a

failover failure is due to link up/down on an interface.

In the third example of show failover output in the Cisco LocalDirector Installation and

Configuration Guide, the IP addresses in the display were incorrect. The following example is

correct:

The following example shows that a failure has been detected. Note that interface 1 on the primary

unit is the source of the failure. The units are back in waiting mode because of the failure. The failed

unit has removed itself from the network (interfaces are down) and it is no longer sending hello

packets on the network. The active unit will remain in the waiting state until the failed unit is

replaced and failover communications start again.

ld-prim(config)# show failover

Failover On

Cable status: Normal

This host: Primary - Standby (Failed)

Active time: 7140 (sec)

Interface 0 (192.168.89.2): Normal (Waiting)

Interface 1 (192.168.89.2): Failed (Waiting)

Other host: Secondary - Active

Active time: 30 (sec)






New or Changed Commands

FDDI

A FDDI interface option is available with version 1.6.3 of LocalDirector. Each FDDI card is a

dual-attach with two SC connectors.

Note Port-B is on the top of the FDDI card, and Port-A is on the bottom.

Gratuitous ARPs

Gratuitous ARPs are supported in version 1.6.

Slowstart

The slowstart feature is optional on a per virtual server basis, and the predictor command has

changed in 1.6 to support slowstart.

Source MAC address

In version 1.5, when the LocalDirector would transmit a packet, it would copy its MAC address asthe source MAC address of the packet when it forwarded the packet to a real machine. In version

1.6, the LocalDirector functions more as a transparent bridge in that all transmitted packets keep the

source MAC address of the sending host.

Thus, in version 1.6 the only packets that will have the LocalDirector as the source MAC address

are the following:

• Telnet connections

• Any pings that are done from the LocalDirector console

• HELLO messages for failover

Note All LocalDirector units will emit failover HELLO messages regardless of whether or not

failover is being used. This is required for LocalDirector to work in a switched environment.

New or Changed CommandsThe following sections describe new or changed commands in this release:

• data

• failover

• mtu

• name

• ping

• predictor

• show real

• show virtual

• snmp-server

• timeout

• weight





data

The data command limits the number of connections to real servers running the HTTP daemon, but

are not sending data because the daemon is down. Some webservers (especially those running

Microsoft Windows NT 4.0) will continue to establish connections to a real server even though the

daemon or application running on that port is dead. The LocalDirector does not recognize this as a

real machine failure, but the data command can be used to limit the number of connections sent to

a server that is not sending data for established connections.

Syntax Description

Note The number variable for the mtu command has changed to number of connections in

LocalDirector version 1.6.3.

failover

The failover command enables access to the optional failover feature. The failover command

without an argument indicates that you have connected the optional failover cable from your primary

LocalDirector to a secondary LocalDirector. The default is no failover; however, if the failover cable

is present at boot-up, it will be detected and failover will be enabled automatically. Use the show

failover command to verify the status of the connection and to determine which unit is active.

Failover works by passing control to the secondary unit should the primary unit fail. The switch

between units occurs within 30 seconds of the failure event. The markings on the failover cable letyou choose which unit is primary and which is secondary. Refer to Installing the Failover Connector

Assembly and Cable (Document Number 78-3749-02) supplied with the failover cable option for

more information about upgrading an existing LocalDirector unit to accept the failover cable.

Syntax Description

real_id The IP address or name of a real server.

number of connections The number of connections to allow to a real server where data has

been requested, but no data has been sent by the server. The feature is

disabled by default with an initial value of 0.

[active] Make a LocalDirector the active unit. Use this command to make a primary unit active

after it has been out of service, or to make a secondary unit active so the primary unit can

be taken offline for maintenance. Either enter no failover active on the secondary unit to

switch service back to the primary, or enter failover active on the primary unit.

ip address This IP address will be used by the standby unit to communicate with the active unit. Use

this IP address with the ping command to check the status of the standby unit. Thisaddress must be on the same network as the system IP address. For example, if the

system IP address is 192.168.123.1, set the failover IP address to 192.168.123.2.

reset Forces both units back to an unfailed state. Use this command instead of rebooting the

LocalDirector. This will not cause a switch to occur, and if the LocalDirector still has

problems, it will be failed again.





mtu

The val variable for the mtu command has changed to bytes in version 1.6.3.

Syntax Description

name

The name command now has a no option that will remove a name associated with a real or virtual

server.

ping

The ping command no longer requires that you specify an interface number.

Syntax Description

predictor

The predictor command now lets you select either roundrobin or none as slowstart options for use

with the leastconns or weighted arguments. The LocalDirector will rotate through the servers until

the number of connections reaches a pre-determined level when slowstart is enabled. This avoidsoverloading a server with too many requests when it is brought in-service. The slowstart option is

enabled by default.

Syntax Description

unit The interface (0 or 1) for which the MTU is being specified.

bytes The MTU for the interface. Specify a number between 64 and 65,535.

ip The IP address of a host on the network.

virtual_id The IP address or name of the virtual server.

fastest Assigns new connections to the physical server with the fastest predicted response time.

roundrobin Rotates through the list of physical servers bound to virtual, assigning connections to the

next server.

leastconns Assigns new connections to the physical server that has the least number of currentconnections. This is the default.

weighted Assigns new connections based on values set with the weight command. The default

weight for each server is one.

none Disables slowstart for the virtual server. Use the roundrobin option to enable slowstart.





show real

The show real command output now includes the DataIn counter, which counts the number of

clients requesting but not receiving data.

For example:

LocalDirector(config)# show real

Real Machines:

No Answer TCP Reset DataIn

Machine Port Connect State Thresh Reassigns Reassigns Conns

server1 default 0 IS 8 0 0 0

server2 default 0 IS 8 0 0 0

LocalDirector(config)#

show virtual

The show virtual command output now displays the predictor and slowstart predictor options. An

asterisk (*) is shown next to the active predictor. This indicates whether the virtual server is using

the selected predictor value, or is in slowstart mode.

For example:

LocalDirector(config)# show virtual

Virtual Machines:

Machine Port State Connect Sticky Predictor Slowstart

192.168.0.99 default OOS 0 0 leastconns* roundrobin

snmp-server

The ip_address variable for the snmp-server host command has changed to ipaddr . Also, the snmp

commands now accept a no option.

Syntax Descriptioncontact Indicates that you are supplying your name or that of the

LocalDirector system administrator.

location Indicates that you are specifying your LocalDirector location.

host Indicates that you are specifying an IP address of a host to which

SNMP traps should be sent. You can specify a maximum of five host

IP addresses, one per command.

text When used with contact, specify your name or that of the

LocalDirector system administrator. When used with location, specify

your LocalDirector location.

ipaddr When used with host, the IP address of a host to which SNMP traps

should be sent. You can specify a maximum of five host IP addresses.





timeout

The minutes variable for the timeout command has changed to idle_minutes in version 1.6.3.

Syntax Description

weight

The weight command now has a no option that will remove a weight value associated with a real

server.

real_id Real server IP address or name.

idle_minutes The number of minutes the server maintains a connection before

dropping it. The default is 120 minutes, and the minimum is 5

minutes.




Cisco Connection Online

Cisco Connection OnlineCisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance

customers and partners can self-register on CCO to obtain additional information and services.

Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added

services to Cisco's customers and business partners. CCO services include product information,product documentation, software updates, release notes, technical tips, the Bug Navigator,

configuration notes, brochures, descriptions of service offerings, and download access to public and

authorized files.

CCO serves a wide variety of users through two interfaces that are updated and enhanced

simultaneously: a character-based version and a multimedia version that resides on the World Wide

Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet

e-mail, and it is excellent for quick access to information over lower bandwidths. The WWW version

of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well

as hyperlinks to related information.

You can access CCO in the following ways:

• WWW: http://www.cisco.com• WWW: http://www-europe.cisco.com

• WWW: http://www-china.cisco.com

• Telnet: cco.cisco.com

• Modem: From North America, 408 526-8070; from Europe, 33 1 64 46 40 82. Use the following

terminal settings: VT100 emulation; databits: 8; parity: none; stop bits: 1; and connection rates

up to 28.8 kbps.

For a copy of CCO's Frequently Asked Questions (FAQ), contact [email protected]. For

additional information, contact [email protected].

If you are a network administrator and need personal technical assistance with a Cisco product that

is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center(TAC) at 800 553-2447, 408 526-7209, or [email protected]. To obtain general information about

Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or

[email protected].

CD-ROM DocumentationCisco documentation and additional literature are available in a CD-ROM package, which ships with

your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated

monthly. Therefore, it might be more up to date than printed documentation. To order additional

copies of the Documentation CD-ROM, contact your local sales representative or call customer

service. The CD-ROM package is available as a single package or as an annual subscription. You

can also access Cisco documentation on the World Wide Web at http://www.cisco.com,http://www-china.cisco.com, or http://www-europe.cisco.com.

If you are reading Cisco product documentation on the World Wide Web, you can submit comments

electronically. Click Feedback on the title bar, and then select Documentation. After you complete

the form, click Submit to send it to Cisco. We appreciate your comments.




CD-ROM Documentation

This document is to be used in conjunction with the Cisco LocalDirector Installation and Configuration Guide publication.

AccessPath, AtmDirector, Cache Director System, CD-PAC, Cisco IOS, the Cisco IOS logo, CiscoLink , the Cisco Powered Network logo, ClickStart, ControlStream, Fast Step,

FragmentFree, IGX, JumpStart, LAN2LAN Enterprise, LAN2LAN Remote Office, MICA, NetBeyond, NetFlow, Netsys Technologies, Packet , PIX, Point and Click Internetworking,

RouteStream, SMARTnet, StrataSphere, StrataSphere BILLder, StrataSphere Connection Manager, StrataSphere Modeler, StrataSphere Optimizer, Stratm, StreamView, SwitchProbe,The Cell, TokenSwitch, TrafficDirector, VirtualStream, VlanDirector, Workgroup Director, Workgroup Stack, and XCI are trademarks; The Network Works. No Excuses. is a service mark;

and BPX, Catalyst, Cisco, Cisco Systems, the Cisco Systems logo, EtherChannel, FastHub, FastPacket, ForeSight, IPX, LightStream, OptiClass, Phase/IP, StrataCom, and StrataView Plus

are registered trademarks of Cisco Systems, Inc. in the U.S. and certain other countries. All other trademarks mentioned in this document are the property of their respective owners.

Copyright © 1997, Cisco Systems, Inc.

All rights reserved. Printed in USA.

978R



About This Guide xi

About This Guide

Document ObjectivesThis guide provides installation and configuration information for the Cisco LocalDirector,

a device that intelligently load balances network traffic across servers and speeds user

access to server-based applications. LocalDirector also distributes TCP services across

multiple servers and serves multiple domains from a single server transparently.

AudienceThis guide is for network managers who perform any of the following tasks:

• Installing and configuring TCP servers or World Wide Web servers

• Managing TCP services

Document Organization• Chapter 1, “Introduction,” provides an overview of LocalDirector features and

equipment, and describes LocalDirector concepts.

• Chapter 2, “Installing LocalDirector,” provides instructions for installing

LocalDirector.

• Chapter 3, “Configuring LocalDirector,” describes configuring LocalDirector and

provides sample configurations.

• Chapter 4, “Command Reference,” describes LocalDirector commands including

usage, syntax, options, and examples.

• Appendix A, “LocalDirector Hot-Standby Failover,” provides a description of theoptional LocalDirector standby failover.

• Appendix B, “Load Balancing Options,” describes the options for determining load

balancing.



xii Cisco LocalDirector Installation and Configuration Guide

Document Conventions

• Appendix C, “Troubleshooting,” provides troubleshooting tips.

Document ConventionsThis guide uses the following conventions:

• The symbol ^ represents the key labeled Ctrl (Control). To enter a control key; for

example, ^z, hold down the Ctrl key while you press the z key.

• Commands and keywords are in boldface.

• File names, directory names, and arguments for which you supply values are in initalics.

• Elements in square brackets ([]) are optional.

• Alternative but required keywords are grouped in braces ({}) and are separated by

vertical bars (|).

• Terminal sessions are printed in a screen font.

• Information you need to enter is in a boldface screen font.

Note Means reader take note. Notes contain helpful suggestions or references to material

not covered in the manual.

CD-ROM DocumentationCisco documentation and additional literature are available in a CD-ROM package, which

ships with your product. The Documentation CD-ROM, a member of the Cisco

Connection Family, is updated monthly. Therefore, it might be more up to date than printed

documentation. To order additional copies of the Documentation CD-ROM, contact your

local sales representative or call customer service. The CD-ROM package is available as a

single package or as an annual subscription. You can also access Cisco documentation on

the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or

http://www-europe.cisco.com.



About This Guide xiii


If you are reading Cisco product documentation on the World Wide Web, you can submit

comments electronically. Click Feedback on the title bar, and then select Documentation.

After you complete the form, click Submit to send it to Cisco. We appreciate your

comments.

Cisco Connection OnlineCisco Connection Online (CCO) is Cisco Systems’ primary, real-time support channel.

Maintenance customers and partners can self-register on CCO to obtain additional content

and services.

Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and

value-added services to Cisco’s customers and business partners. CCO services include

product information, software updates, release notes, technical tips, the Bug Navigator,

configuration notes, brochures, descriptions of service offerings, and download access to

public and authorized files.

CCO serves a wide variety of users through two interfaces that are updated and enhanced

simultaneously: a character-based version and a multimedia version that resides on the

World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit,

Xmodem, FTP, and Internet e-mail, and is excellent for quick access to information over

lower bandwidths. The WWW version of CCO provides richly formatted documents with

photographs, figures, graphics, and video, as well as hyperlinks to related information.

You can access CCO in the following ways:

• WWW: http://www.cisco.com.

• WWW: http://www-europe.cisco.com.

• WWW: http://www-china.cisco.com.

• Telnet: cco.cisco.com.

• Modem: From North America , 408 526-8070; from Europe , 33 1 64 46 40 82. Use the

following terminal settings: VT100 emulation; databits: 8; parity: none; stop bits: 1; and

connection rates up to 28.8 kbps.

For a copy of CCO’s Frequently Asked Questions (FAQ), contact [email protected]. For

additional information, contact [email protected].



xiv Cisco LocalDirector Installation and Configuration Guide


Note If you are a network administrator and need personal technical assistance with a

Cisco product that is under warranty or covered by a maintenance contract, contact Cisco’s

Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or [email protected]. To

obtain general information about Cisco Systems, Cisco products, or upgrades, contact

800 553-6387, 408 526-7208, or [email protected].

Technical AssistanceIf you contact technical support regarding your LocalDirector configuration, have the

following items ready before you call:

• A diagram of your network including IP addresses and subnet masks

• A copy of the following output from your LocalDirector:

— show real

— show virtual

— show name

— show bind

— show configuration

— show version— show interface

— show syslog



Load Balancing Options B-1

A P P E N D I X B

Load Balancing Options

The predictor command options and the maxconns command allow you to optimize the

response curve of the entire system. These options are described in the following sections:

• Least Connections

• Weighted Percentage

• Round Robin

• Fastest

• Maximum Connections

Least Connections

The leastconns predictor option directs network connections to the server with the leastnumber of open connections. Although it may not be intuitively obvious that the leastconns

predictor would provide effective load balancing; in fact, it does quite well. At web sites

where there is a collection of servers with similar performance, the leastconns option is

effective in smoothing distribution in situations where a server gets bogged down for one

reason or another. In sites where there are large differences in the capacity of various

servers, the leastconns option also performs very well. In maintaining the same amount of

connections to all servers, those capable of processing (and thus terminating) connections

the fastest will get more connections over time. A server deemed to be twice as powerful

as another server does, in fact, get about twice as many connections per second.



B-2 Cisco LocalDirector Installation and Configuration Guide

Weighted Percentage

Weighted PercentageThe weighted predictor option allows you to assign a performance weight to each server.

Weighted load balancing is similar to leastconns, but servers with a higher weight value

will receive a larger percentage of connections at any one time. LocalDirector

administrators can assign a weight to each real server, and the LocalDirector will use this

weight to determine the percentage of the current number of connections to give each

server. The default weight is one.

For example, in a configuration with 5 servers, the percentage of connections is calculated

as follows:

weight server1 7

weight server2 8

weight server3 2

weight server4 2

weight server5 5

total weight of all servers = 24

This will result in server1 getting 7/24 of the current number of connections, server2 getting

8/24, server3 getting 2/24, etc. If a new server, server6, is added with a weight of 10, it will

get 10/34, and so on. Thus, the weighted option allows an administrator to fine tune

LocalDirector load balancing for the web site.

Note The weight command is used to set the weight values for the real servers, and the

predictor command is used to set load balancing to the weighted option.

Round RobinThe roundrobin predictor option directs the network connection to the next server, and

treats all servers as equals regardless of number of connections or response time. Although

the LocalDirector roundrobin predictor appears similar to DNS round robin, it is superior

because there is no propagation delay or caching that will hinder the algorithm. Also, the

LocalDirector can determine when a server is not responding, and avoid sending

connections to that server.



Load Balancing Options B-3

Fastest

FastestThe fastest predictor option directs the network connection to the server with the fastest

response rate, although it does not perform consistently in varying server configurations.

Web-server performance, in particular, does not follow a linear progression of response

time to number of connections. Web servers seem to respond flatly to a point, and then at

a certain load there is a sharp, dramatic increase in the response time. In these situations,

the fastest predictor will tend to overload a particular server before moving on to another.

Maximum ConnectionsUse the maxconns command to specify the maximum number of connections for each real

server. By setting a limit to the maximum connections that a server will accept, you can

avoid exceeding the capacity threshold of the server.



B-4 Cisco LocalDirector Installation and Configuration Guide

Maximum Connections



C H A P T E R

Introduction 1-1

1

Introduction

Cisco LocalDirector (see Figure 1-1) is a hardware and software solution with a secure,

real-time, embedded operating system that intelligently load balances TCP/IP traffic acrossmultiple servers. Delivering very fast performance by distributing client requests across a

cluster of low-cost servers, LocalDirector dramatically reduces the cost of providing

large-scale Internet services, and speeds user access to those applications.

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.

Figure 1-1 LocalDirector Bridge Between Internet and Servers

The load-balancing options of LocalDirector provide a flexible and adaptable method for

directing TCP/IP traffic. You can configure LocalDirector to maximize the number of

TCP/IP connections a server farm can manage. TCP/IP traffic is directed to different servers

based on service, speed, or quantity of connections.

Note LocalDirector provides load balancing for TCP/IP connections only.

S 5 8 2 5

LocalDirector(bridge)

Segment 1

(VLAN1)

Segment 2

(VLAN2)

Hub or switchHub or switch

Server A

Server B

Server C

Server D

Clients



1-2 Cisco LocalDirector Installation and Configuration Guide

LocalDirector Features

LocalDirector is a high-performance Internet appliance with over 92 Mbps throughput. It

supports a combined total of 10,240 virtual IP addresses and real servers. The real servers

can be a collection of heterogeneous hardware platforms and operating systems. Quick

setup with no network address changes reduces system administration time.

Ideal for mission-critical applications, LocalDirector provides the capability to build a

highly redundant and fault-tolerant server system. Servers are automatically and

transparently placed in and out of service, providing fault tolerance for servers.

LocalDirector itself is equipped with an optional hot-standby failover mechanism, building

increased redundancy for the server system. Figure 1-2 shows the front of the

LocalDirector.

Figure 1-2 LocalDirector Front View

LocalDirector FeaturesLocalDirector has these features:

• Hot-standby/failover (optional)—Enables configuration of highly redundant,

fault-tolerant systems.

• Provides over 92 Mbps throughput with 500 byte packets and greater—Scalable to meet

the needs of large Web sites.• Real-time embedded operating system—Provides full utilization of the hardware, CPU,

and memory.

• Setup is simple—does not disrupt existing network.

H 7 8 7 3



Introduction 1-3

LocalDirector Equipment

• Configurable with a total of 10,240 virtual addresses and physical addresses—Provides

flexibility in domain names and network configuration.

• Supports 600,000 simultaneous TCP connections.

• Transparent support for all common TCP/IP Internet services—Web, File Transfer

Protocol (FTP), Telnet, Gopher, and Simple Mail Transfer Protocol (SMTP) are all

supported without special software configuration.

• Easy administration of servers—Add and remove servers transparently, and increase

quantities of servers as traffic grows.

• Compatible with any server operating system—Administrators are able to mix andmatch server hardware and operating systems to retain technology investments.

LocalDirector EquipmentThe LocalDirector shipping carton contains the following:

• Rack-mountable LocalDirector unit:

— 19-inch rack-mount enclosure

— Two Ethernet 10/100 network interfaces with RJ45 connectors

Optional Fiber Distributed Data Interface (FDDI) with SC connectors

— Data bus (DB)-9 EIA/TIA-232 console interface port

— 3.5-inch diskette drive

— 32 MB of RAM

— 2 MB of Flash memory

— 200 MHz Pentium Pro processor

• Keys for the front panel lock

• Power cord

• DB-9 to DB-25 null modem serial cable

• DB-25 gender adapter

•LocalDirector system diskette

• This guide

• Cisco LocalDirector Release Notes

• Regulatory Compliance and Safety Information for the Cisco LocalDirector




Before Installing LocalDirector

Before Installing LocalDirector

Note Read the Regulatory Compliance and Safety Information for the Cisco

LocalDirector before installing. Even though you probably read safety guidelines for the

other products in your network, studying the material in this guide and the brief section that

follows can help keep you safe and focused as you continue preparing your LocalDirector

for service.

Follow these guidelines to ensure general safety:

• Keep the chassis area clear and dust-free during and after installation.

• Put the removed chassis cover in a safe place.

• Keep tools away from walk areas where you and others could fall over them.

• Do not wear loose clothing that could get caught in the chassis. Fasten your tie or scarf

and roll up your sleeves.

• Wear safety glasses if you are working under any conditions that might be hazardous to

your eyes.

• Do not perform any action that creates a potential hazard to people or makes the

equipment unsafe.

Access ModesThe command interpreter provides a command set that emulates Cisco IOS technologies.

This command set provides three administrator access modes:

• Unprivileged mode displays the “>” prompt and lets you view current running settings.

• Privileged mode displays the “#” prompt and lets you change current settings and write

to flash memory. Unprivileged commands also work in privileged mode.

• Configuration mode displays the “(config)#” prompt and lets you change system

configurations. Configuration mode commands work only in this mode.



Introduction 1-5

LocalDirector Concepts

At startup, the console is in unprivileged mode. You can access privileged mode by entering

the enable command. LocalDirector then prompts you for a password. When you first

configure LocalDirector, a password is not required. Press the Enter key at the prompt.

Assign a password to privileged mode with the enable password command. Exit privileged

mode by entering the disable command.

Access configuration mode by entering the configure terminal command while in the

privileged mode. You can then write your settings to flash memory, diskette, or to your

console computer. Exit configuration mode by entering ^Z.

When you enter commands, you can erase characters with the Backspace or Del key. You

can erase the previous word with ^W and erase the previous line with ^U.

LocalDirector ConceptsLocalDirector concepts covered in this section include the following:

• LocalDirector Bridging Feature

• Virtual and Real Servers

• Server Backup

• Failed Server Recovery

• Slowstart

LocalDirector Bridging FeatureLocalDirector 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 with a

single way in or out to the network.

If there is another path from the network to your servers, a bridge loop will be created and

LocalDirector will not work properly. The LocalDirector automatically detects a bridge

loop and tries to recover. SYSLOG messages will be generated to indicate that there is a

bridge loop.





Virtual and Real ServersVirtual servers present a single address for a group of real servers and load-balance service

requests between the real servers in a site. Real servers are actual host machines with

unique IP addresses that provide TCP/IP services to the network. The virtual server IP

address is published to the user community, but the real IP addresses can remain

unpublished, allowing you to hide actual site implementation details and provide single

points of contact for users.

Clients and servers cannot be located on the same side of the LocalDirector. The

LocalDirector uses network address translation (NAT) to make it appear as if the client is

communicating directly with the real servers. If the client and server are on the samenetwork segment, the response from the server will bypass the LocalDirector and the traffic

will not be load balanced. All traffic must pass through the LocalDirector and be bridged

to the real servers.

Virtual servers and real servers can also be seen as a “TCP service” instead of just an IP

address. When you define virtual and real servers, you can specify the port traffic that will

run on the server. These servers are referred to as port-bound servers, and they provide the

following benefits:

• You can configure application-specific server farms. In other words, with one virtual IP

address and multiple virtual ports, File Transfer Protocol (FTP) traffic can be directed

to one server farm, and HyperText Transfer Protocol (HTTP) traffic can be sent to

another, allowing you to dedicate servers to specific tasks and allocate resources more

efficiently.

• You can deny or accept access to a server based on service. For example, LocalDirector

can deny all TCP traffic except for HTTP traffic, providing an increased level of

security.

• You can continue to access services on a server that has a failed service daemon. If a

particular daemon fails, only that daemon or port will fail, not the entire server. For

example, multiple Web daemons might be running on the same server, and if one of the

Web daemons fails, only that daemon will fail and not the whole server. This setup

increases server farm reliability.

Note If you have a port-bound virtual server (for example, 192.168.89.220 80) traffic to

any other port on the virtual server will result in a reset being sent to the client machine

requesting the connection.



Introduction 1-7


Server BackupTo ensure that TCP services will continue to run in the event that a server is failed or

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 the 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 is failed or out-of-service. For a virtual

server, a backup is used if all real servers (and their backups) bound to the virtual server are

failed or out-of-service. If the virtual server itself is out-of-service, a reset message will be

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 will be displayed.

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.

Failed Server RecoveryWhen a real server is failed (it does not respond to a predetermined number of connections

set by the threshold command), the following process is used to test the real server to see

if it is ready to accept more connections:

• After the number of minutes set with the retry command have passed, the real server

will be put into “TESTING” state. The default for the retry command is one minute. If

the show real command is used while in the testing state, TESTING will be displayed

in the output.

• In the testing state, the server will receive one live connection from a client. If the server

responds, it will be moved back into “IS” (in-service) state; however, if the real server

does not respond, it will be moved back to “FAILED” state and it will be retried again,

after the number of minutes set with the retry command have passed (as before).





SlowstartPreviously, a server brought into service under heavy network traffic would be bombarded

with connections since it had zero connections. The effect of too many connections at once

would disable servers or seriously decrease their performance.

An automatic slowstart algorithm is available to help bring new servers up to speed with

the weighted or leastconns predictor options. The slowstart option can be set to

roundrobin or none. The roundrobin slowstart option will load balance network

connections until network traffic is stable. When the number of connections on all bound

real servers is within 80 percent of the desired distribution, the predictor will switch to

either weighted or leastconns, as specified in the configuration.Slowstart is used when:

• A new real server is bound to a virtual server

• A virtual server just comes out of being failed to in-service

• A real server is taken from failed or out of service to in-service

• The predictor option for the virtual server is changed

Note Slowstart is only used with leastconns and weighted predictors, and it is optional in

version 1.6 and later. For more information, see the predictor command page in Chapter 4,

“Command Reference.”



C H A P T E R

Configuring LocalDirector 3-1

3

Configuring LocalDirector

You can configure LocalDirector to specify general parameters, and also define real and

virtual servers.

Configuration Guidelines

Determine network and server design, and diagram the implementation. 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 NIC-allocated network number.

The section, “Configuration Examples,” later in this chapter provides details for

implementing different LocalDirector configurations.

Basic LocalDirector Configuration

Connect to the LocalDirector via the console with settings 9600, 8-N-1 as described in

Chapter 2, “Installing LocalDirector.” Enter the enable command in unprivileged mode

and configure terminal in privileged mode to access LocalDirector configuration

commands. Configure LocalDirector as follows:

Step 1 Assign the LocalDirector IP address and subnet mask with the ip address

command.

Step 2 Change the privileged mode password with the enable password command.

Step 3 If preferred, change the host name for the LocalDirector command line prompt

with the hostname command.

Step 4 Define virtual servers with the virtual command and specify the type of port

traffic the virtual server will load balance.

Step 5 Set the type of load balancing for each virtual server with the predictor

command.

ld16ch3 Page 1 Tuesday, August 18, 1998 11:47 AM




Basic LocalDirector Configuration

Step 6 Define real servers with the real command and specify the port traffic that will

run on the server.

Step 7 Associate each virtual server to real server(s) with the bind command.

Step 8 Designate real and virtual servers as in service with the in-service command.

Step 9 Check the configuration by using the write terminal, show real, show virtual,

and show bind commands.

Step 10 Store the configuration in flash memory with the write memory command. The

configuration stored in flash memory can be verified with the show config

command.

The basic configuration is complete. Exit configuration mode by entering ^Z, and exit

privileged mode with the disable command.

The following is an example of a basic configuration with one virtual server bound to two

real servers:

LocalDirector# show configuration

: Saved

: Local Director Version 1.6.3

syslog output 20.3

no syslog console

hostname LocalDirector

interface ethernet 0 auto


ip address 192.168.1.89 255.255.255.0

no rip passive

no failover

virtual 192.168.1.99 is

predictor 192.168.1.99 leastconns

real 192.168.1.2 is

real 192.168.1.1 is

bind 192.168.1.99 192.168.1.1

bind 192.168.1.99 192.168.1.2

no snmp-server contact

no snmp-server location

LocalDirector#





Server Failure Adjustments


If a server is not responding to requests or responding with TCP RSTs, LocalDirector will

fail the server. There are two cases when a real server will respond with a TCP RST:

• The daemon servicing that type of traffic is down (for example, the HTTP daemon on

port 80 has failed).

• The server is too busy to accept any more connections.

Values set with the reassign and threshold commands are used to determine if a server is

considered failed, and these commands can be used to adjust how quickly a server that is

not accepting connections will be taken out of service. The default threshold value is 8, and

the default reassign value is 3. Each real server can have different threshold and reassign

values.

The reassign command controls how many times a packet from a requesting client is sent

to a non-responding server before it is reassigned to another server. The default is three

attempts. After the third packet receives no response or a TCP RST from the server, the

fourth packet is sent to another server.

Each reassign process increments the threshold tally by one. When the tally reaches the

threshold value, the server is considered failed. With a default threshold value of 8, the

reassign process will happen eight times before the server is considered failed.

To increase how quickly servers are considered failed, reduce the threshold and reassign

values. To keep servers that are refusing connections from being failed by theLocalDirector, increase the thresholdandreassign values. Forexample, a site receiving 400

connections per second may need to increase the threshold value to 30.

The retry command determines how quickly a server is put in “testing” mode and given

another packet after being failed by this process. The retry default is 60 seconds. On the

sixty first second, a packet from a virtual server will be directed to the server to determine

if it responds. If that packet receives a response, the server is no longer in the failed state,

and it will be put back in-service with the reassign and threshold tallies reset to zero. To

increase how quickly a server is given a packet after being failed by LocalDirector, reduce

the value of the retry command.

Note Since a live connection is used to retry a failed server, a virtual server bound to thereal server must also receive a connection to send to it. If the virtual server has no traffic,

the real server will stay in testing mode regardless of the retry value.






The autounfail command is used to bring a failed server back in-service immediately if it

responds with data on an existing connection (established before it was failed by the

LocalDirector). The LocalDirector will put the server into testing mode, and if it responds

to a new live connection it will then be put in-service. If the server does not accept the new

connection (either by not answering or by responding with a TCP RST), then it will be

marked as failed again.

When autounfail is on (it is by default), LocalDirector will bring theserver back in-service

as soon as it responds to an existing connection. This will bring a server back in service

before waiting for the retry time to pass, and it will only work with servers that are

responding with data.

Use the data command to limit the number of connections sent to a server that is not

sending data. When a real machine reaches thenumber of unanswered connections set with

the data command, the LocalDirector will check to see if other machines bound to the

virtual server are also at 80 percent of their threshold capacity (DataIn value). If the other

machines are close to reaching this value, then the LocalDirector assumes the site is busy

and will not fail the machine.

The timeout command is used to set the number of minutes an idle connection to the server

will be maintained. This will prevent incomplete connections from being counted toward

LocalDirector load balancing.





Configuration Examples


This section provides example server configurations, including the following:

• One Virtual Server and Multiple Real Servers

• Multiple Virtual Servers and One Real Server

• Multiple Virtual Servers and Multiple Real Servers

• Highly Redundant, Fault-Tolerant Configuration

• Application-Specific Servers

• Maximum Connections and Weighted Configuration• Configuring SYSLOG

• Configuring SNMP

• Requesting the Same Server for Multiple Connections

• Configuring for Secure Socket Layer Protocol

• Configuring NT Servers

• UDP/Multimedia Applications

One Virtual Server and Multiple Real Servers

In this example, the LocalDirector is load balancing all TCP traffic over two servers to

provide web services. Figure 3-1 shows the network configuration required.

Figure 3-1 One Virtual Server and Many Real Servers

LocalDirector192.168.1.89 Real IP

192.168.1.1Server 1

Virtual IP192.168.1.99

www.domain.com

Real IP192.168.1.2

Server 2 S 5 8 4 0

Virtual Machine

Clients






All traffic destined for virtual IP address 192.168.1.99 is load balanced across real servers

with IP addresses 192.168.1.1 and 192.168.1.2. Only the virtual server appears in the

Domain Name System (DNS). The following example shows the commands used to set up

this configuration:

The enable command starts privileged mode. Then configure t starts configuration mode:

LocalDirector> enable

Password:

LocalDirector# configure t

The ip address command specifies LocalDirector IP address 192.168.1.89, and subnet

mask 255.255.255.0:LocalDirector(config)# ip address 192.168.1.89 255.255.255.0

The interface ethernet command with the auto option automatically determines the speed

of the Ethernet interface:

LocalDirector(config)# interface ethernet 0 auto

LocalDirector(config)# interface ethernet 1 auto

The no failover command indicates that the failover option is not being used:

LocalDirector(config)# no failover

The name command is used to identify 192.168.1.99 as www.site.com, and then thevirtual

command is used to define www.site.com as a virtual server:

LocalDirector(config)# name 192.168.1.99 www.site.com LocalDirector(config)# virtual www.site.com

The name command is used to identify IP address 192.168.1.1 as server1 and 192.168.1.2

as server2:

LocalDirector(config)# name 192.168.1.1 server1

LocalDirector(config)# name 192.168.1.2 server2

The real command is used to identify server1 and server2 as real servers, and the is

(in-service) option enables the real servers to start accepting connections:

LocalDirector(config)# real server1 is

LocalDirector(config)# real server2 is

The bind command associates www.site.com with server1 and server2 and establishes the

load-balancing relationship between the virtual and real servers:LocalDirector(config)# bind www.site.com server1 server2

The is (in-service) command brings the virtual server in-service:

LocalDirector(config)# is virtual www.site.com






Finally, the write mem command saves the new settings:

LocalDirector(config)# write mem

Building configuration...

[OK]

Except for failover, thedefault settings for LocalDirector were not changed in this example:

• No SYSLOG console is defined

• Routing Information Protocol (RIP) is not on

• Timeout is 120 minutes

• Sticky is 0 (disabled)• Reassign is 3

• Threshold is 8

• Retry is 1

• Predictor is leastconns

• Weight is 1

• Autounfail is on

Use the write terminalcommand to view the running configurationbefore it is saved. View

the saved configuration with the show configuration command, as follows:

LocalDirector# show configuration

: Saved: Local Director Version 1.6.3

syslog output 20.3

no syslog console

hostname LocalDirector



ip address 192.168.1.89 255.255.255.0

no rip passive

no failover

virtual 192.168.1.99 is

predictor 192.168.1.99 leastconns

real 192.168.1.2 is

real 192.168.1.1 is

name 192.168.1.1 server1

name 192.168.1.2 server2

name 192.168.1.99 www.site.com

bind 192.168.1.99 192.168.1.1

bind 192.168.1.99 192.168.1.2

no snmp-server contact

no snmp-server location

LocalDirector#






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-2, allowing you to provide multiple DNS entries with 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 www.pete.com,

www.joe.com, www.scott.com, and www.mary.com, respectively. Port 80 traffic for each

virtual IP address is bound to different ports on real server IP 192.168.1.2.

All web traffic destined for www.pete.com will access information on real server

192.168.1.2 through port 8000. Traffic destined for www.joe.com will access information

on real server 192.168.1.2 through port 8001, and so on.

Figure 3-2 Many Virtual Servers and One Real Server

Also, by defining a virtual server as an IP address and a port, you can restrict traffic to a

specific port. Port 80 is specified for each of the virtual servers, and ports 8000, 8001, 8002,

and 8003 are specified for the real server. The virtual server ports and real server ports are

bound to each other directly. In addition, if the application running on port 8000 fails, the

entire server will not be taken out of service by the LocalDirector solution; the remaining

ports will continue to accept connections.

A configuration example follows:

The name command is used to identify the IP addresses of the virtual and real servers:

LocalDirector(config)# name 192.168.1.99 www.pete.com

LocalDirector(config)# name 192.168.1.100 www.joe.com

LocalDirector(config)# name 192.168.1.101 www.scott.com

LocalDirector(config)# name 192.168.1.102 www.mary.com

LocalDirector(config)# name 192.168.1.2 server

domain1domain2domain3

domain4

Domain Name

192.168.1.99192.168.1.100192.168.1.101

192.168.1.102

Virtual IP

192.168.1.2192.168.1.2192.168.1.2

192.168.1.2

Real IP

800080018002

8003

808080

80

PortPort

S 5 8 4 2

Virtual 1Virtual 2Virtual 3Virtual 4

Clients






The real command is used to identify the IP address named “server” as a real server that is

accepting connections on ports 8000, 8001, 8002, and 8003:

LocalDirector(config)# real server 8000




The virtual command is used to identify the named IP addresses “www.pete.com,”

“www.joe.com,” “www.scott.com,” and “www.mary.com” as virtual servers accepting

connections on port 80:

LocalDirector(config)# virtual www.pete.com 80

LocalDirector(config)# virtual www.joe.com 80

LocalDirector(config)# virtual www.scott.com 80

LocalDirector(config)# virtual www.mary.com 80

The bind command is used to direct port 80 network traffic from each virtual server to a

different port on the real server:

LocalDirector(config)# bind www.pete.com 80 server 8000

LocalDirector(config)# bind www.joe.com 80 server 8001

LocalDirector(config)# bind www.scott.com 80 server 8002

LocalDirector(config)# bind www.mary.com 80 server 8003

The is (in-service) command is used with the all option to indicate that all ports of the real

server are in service:

LocalDirector(config)# is real server all

The is (in-service) command is used to indicate that the virtual servers are in service:

LocalDirector(config)# is virtual www.pete.com 80

LocalDirector(config)# is virtual www.joe.com 80

LocalDirector(config)# is virtual www.scott.com 80

LocalDirector(config)# is virtual www.mary.com 80

The show bind command is used to view the association between the virtual server ports

and real server ports:

LocalDirector(config)# show bind

Virtual Real

www.pete.com 80 (IS)

server 8000 (IS)

www.joe.com 80 (IS)

server 8001 (IS)

www.scott.com 80 (IS)

server 8002 (IS)

www.mary.com 80 (IS)

server 8003 (IS)







Multiple Virtual Servers and Multiple Real Servers

You can combine multiple virtual and real servers so that each virtual server sends network

traffic to the same port across real servers, as shown in Figure 3-3. All 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-4.

Each virtual server can have a different load balancing option set with the predictorcommand. For example, 192.168.1.100 canbe configured to use the leastconns option, and

192.168.1.101 can be configured to use the weighted option.

Figure 3-3 Multiple Virtual and Real Servers

192.168.1.1192.168.1.1

Real IP

192.168.1.2192.168.1.2

192.168.1.3192.168.1.3

80018002

Port

80018002

80018002

192.168.1.100Port 80

Virtual IP

192.168.1.1192.168.1.2192.168.1.3

Real IP

800180018001

Port

192.168.1.101Port 80

domain 1

www.domain1.com

Domain Name

domain 2

www.domain2.com

192.168.1.1192.168.1.2192.168.1.3

800280028002

8080

Port

S 5 8 4 1

Clients

Virtual IP192.168.1.100192.168.1.101







The real command is used to identify three real servers, each accepting connections on

ports 8001 and 8002. The is (in-service) option is used to indicate that the real servers are

in service:

LocalDirector(config)# real 192.168.1.1 8001 is






The virtual command is used to create two virtual servers accepting connections on

port 80:

LocalDirector(config)# virtual 192.168.1.100 80


The bind command is used to direct network traffic from port 80 on the two virtual servers

to ports 8001 and 8002 on the three real servers:

LocalDirector(config)# bind 192.168.1.100 80 192.168.1.1 8001






The is (in-service) command is used to bring the virtual servers in service:

LocalDirector(config)# is virtual 192.168.1.100 80


The show bind command is used to view the association between the virtual and real

servers:


Virtual Real

192.168.1.100 80 (IS)

192.168.1.3 8001 (IS)

192.168.1.2 8001 (IS)

192.168.1.1 8001 (IS)

192.168.1.101 80 (IS)

192.168.1.3 8002 (IS)

192.168.1.2 8002 (IS)

192.168.1.1 8002 (IS)







In Figure 3-4, TCP connections to www.pete.com are load balanced across real servers

192.168.1.1,192.168.1.2,and 192.168.1.3.Connections to www.joe.com are loadbalanced

across servers 192.168.1.4, 192.168.1.5, and 192.168.1.6.

Figure 3-4 Load Balancing Across Server Clusters

Server Cluster B

Server Cluster A

Virtual IP Address192.168.1.100Load balances acrossServer Cluster A

A1 – 192.168.1.1

A2 – 192.168.1.2

A3 – 192.168.1.3

B1 – 192.168.1.4

B2 – 192.168.1.5

B3 – 192.168.1.6

Virtual IP Address192.168.1.101

Load balances acrossServer Cluster B

192.168.1.100domain 1

www.domain1.com

domain 2

www.domain2.com

Virtual IP AddressDomain Name

192.168.1.1192.168.1.2192.168.1.3

Real IP Address

192.168.1.101 192.168.1.4192.168.1.5192.168.1.6

Bind IP Addresses

S 5 8 4 3

Clients

Virtual IP192.168.1.100192.168.1.101







The real command is used to identify the six real servers, and the is (in-service) option is

used to indicate that the real servers are in service:

LocalDirector(config)# real 192.168.1.1 is






The virtual command is used to identify the two virtual servers:

LocalDirector(config)# virtual 192.168.1.100


The bind command is used to direct network traffic from virtual server 192.168.1.100 to

real servers 192.168.1.1, 192.168.1.2, and 192.168.1.2, and to direct network traffic from

virtual server 192.168.1.101 to real servers 192.168.1.4, 192.168.1.5, and 192.168.1.6:

LocalDirector(config)# bind 192.168.1.100 192.168.1.1 192.168.1.2 192.168.1.3

LocalDirector(config)# bind 192.168.1.101 192.168.1.4 192.168.1.5 192.168.1.6


LocalDirector(config)# is virtual 192.168.1.100



servers:


Virtual Real

192.168.1.100 default (IS)

192.168.1.3 default (IS)

192.168.1.2 default (IS)

192.168.1.1 default (IS)

192.168.1.101 default (IS)

192.168.1.6 default (IS)

192.168.1.5 default (IS)

192.168.1.4 default (IS)







Highly Redundant, Fault-Tolerant ConfigurationFigure 3-5 and Figure 3-6 show highly redundant, fault-tolerant configurations. All ports

on the switches must be on the same virtual LAN (VLAN).

Using Cisco 4500 Series routers and Catalyst 5000 Series switches as examples, the

following commands are used to implement this configuration. This assumes that you are

connected to the unit (via the console or Telnet) and are in configuration mode.

The following provides a command summary and example for configuring the routers:

Command summary:

network <ip address>

offset-list <access-list number or 0 for all networks> in|out <offset>

Example:

router rip

network 192.168.1.0

offset-list 0 out 1

In the example above, router rip accesses the RIP menu. The network command specifies

that the router will broadcast RIP messages for 192.168.1.0. The offset-list command is

used to add 1 to the metric (hop count) associated with the route. This is done on the

secondary router. The primary router is given exactly the same commands without the

offset-list command.

The following provides a command summary and example for configuring the switches:

Command summary:

set vlan <vlan id> <module/port....>

Example:

set vlan 2 1/1,2/1-12

The set vlan command creates a VLAN called vlan 2 which consists of module 1, port 1

and module 2, ports 1 through 12.






Figure 3-5 Fault-Tolerant Configuration, Example 1

Switch 1

VLAN 1

HSRP

Router 1 Router 2

Internet

Failover

Switch 2

Server 1 Server 2 Server n

S 5 8 7 9

SecondaryLocalDirector 2

PrimaryLocalDirector 1

VLAN 2






Figure 3-6 Fault-Tolerant Configuration, Example 2

Router Router

Internet

Weighted metric

Hub 2Hub 1 Crossover

Failover

S 5 8 7 8

LocalDirector 1 LocalDirector 2

Switch

Server 1 Server 2 Server n

VLAN






Application-Specific Servers

TCP services can be directed to specific servers. Figure 3-7 illustrates how to send HTTP

traffic to Servers A and B, and direct all other traffic to Servers C and D. Two virtual servers

have IP address 192.168.1.100; one accepts only HTTP traffic (port 80), and the other

accepts all other connections (default).

Note If you do not specify a port when defining a server, the port will be listed as default.

A server’s default port will accept all network connections, except for those sent to a server

with the same IP address and a specific port identified.

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

Figure 3-7 Application-Specific Servers

A sample configuration follows:

The real command is used to identify tworeal servers acceptingconnections on port 80 and

two real servers accepting default traffic:





Clients

80

23

0(default)

0(default)

Port

Virtual IP

192.168.1.1

Real IP

192.168.1.3

192.168.1.4

192.168.1.2

A

B

C

D S 5 8 3 9

HTTP

Telnet

192.168.1.100:0192.168.1.100:80192.168.1.100:23






The virtual command is used to identify two virtual servers for IP address 192.168.1.100,

one accepting connections on port 80 and the other accepting default traffic:



The bind command is used to direct traffic for virtual server 192.168.1.100, port 80 to

port 80, on real servers 192.168.1.1 and 192.168.1.2:


192.168.1.2 80

The bind command is used to direct all other connections (not port 80) for virtual server

192.168.1.100 to real servers 192.168.1.3 and 192.168.1.4:

LocalDirector(config)# bind 192.168.1.100 192.168.1.3 192.168.1.4


servers:





Virtual Real

192.168.1.100 80 (IS)

192.168.1.2 80 (IS)

192.168.1.1 80 (IS)

192.168.1.100 default (IS)

192.168.1.4 default (IS)

192.168.1.3 default (IS)







Maximum Connections and Weighted Configuration

With the maxconns command you can 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 due to capacity overload. Clients

requesting connections to a serverfarm with no available connections will receive a timeout

message. For more information about optimizing server response time, see Appendix B,

“Load Balancing Options.”

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

with the weight command.

Figure 3-8 shows four servers with varying performance indexes, maximum connections

settings, and weight values set. In this example, a weight of 2 is assigned to the HP 9000

server, which will send 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 Pentium 200 MHz server and the two SPARCStations.

Figure 3-8 Maximum Connections and Weighted Performance

LocalDirector

low-end192.168.1.1

mid-range192.168.1.2

high-end192.168.1.3

high-end192.168.1.3

13%

Percent of

ConnectionsWeight

Totalweight 15

Maximum

Connections

20%

33%

33%

2

3

5

5

500

1000

2000

2000

S 5 8 4 4

Clients







The virtual command is used to identify 192.168.1.100 as a virtual server. The is

(in-service) option indicates that it is in service:

LocalDirector(config)# virtual 192.168.1.100 is

The name command is used to associate a name to the virtual server:

LocalDirector(config)# name 192.168.1.100 www.site.com

The real command is used to identify four real servers. The is (in-service) option indicates

that they are in service:





The name command is used to associate names to the real servers:

LocalDirector(config)# name 192.168.1.1 HP9000

LocalDirector(config)# name 192.168.1.2 pentium200

LocalDirector(config)# name 192.168.1.3 sparc1

LocalDirector(config)# name 192.168.1.4 sparc2

The bind command is used to direct traffic for virtual server www.site.com to real servers

HP9000, pentium200, sparc1, and sparc2:

LocalDirector(config)# bind www.site.com HP9000 pentium200 sparc1 sparc2

The predictor command is used to set load balancing to the weighted option:

LocalDirector(config)# predictor www.site.com weighted

The weight command is used to assign weight values to each of the real servers:

LocalDirector(config)# weight HP9000 2

LocalDirector(config)# weight pentium200 3

LocalDirector(config)# weight sparc1 5

LocalDirector(config)# weight sparc2 5

The maxconns command is used to limit the number of connections that each real server

can accept:

LocalDirector(config)# maxconns HP9000 500

LocalDirector(config)# maxconns pentium200 1000

LocalDirector(config)# maxconns sparc1 2000

LocalDirector(config)# maxconns sparc2 2000






The show real command is used to view the status of the real servers:

LocalDirector(config)# show real

Real Machines:

No Answer TCP Reset DataIn

Machine Port Connect State Thresh Reassigns Reassigns Conns

sparc2 default 0 IS 8 0 0 0

sparc1 default 0 IS 8 0 0 0

pentium200 default 0 IS 8 0 0 0

hp9000 default 0 IS 8 0 0 0


servers:


Virtual Real

www.site.com default (IS)

hp9000 default (IS)

pentium200 default (IS)

sparc1 default (IS)

sparc2 default (IS)

The show weight command is used to view the weight values assigned to the real servers:

LocalDirector(config)# show weight

Machine Port Weight

sparc2 default 5

sparc1 default 5

pentium200 default 3

hp9000 default 2

Configuring SYSLOG

To configure SYSLOG, use the following commands:

• Designate the SYSLOG host with the syslog host command.

• Specify the type of SYSLOG messages to accept with the syslog output command.

• Use show syslog to list the SYSLOG hosts and output level.

To configure a UNIX system to accept SYSLOG messages, take the following steps:

Step 1 Use the LocalDirector syslog host command to configure the LocalDirector to

send SYSLOG messages to the UNIX host’s IP address.






Step 2 Log into the UNIX system as root (superuser) and execute the following

commands; change name to the log file in which you want SYSLOG messages

to appear:

# mkdir /var/log/localdirector

# touch /var/log/localdirector/name

Step 3 While still logged in as root, edit the /etc/syslog.conf filewith a UNIX editorand

add the following selector and action pairs for each message type you want to

capture:

In the syslog.conf file, code each selector and action pair for the messages youwant to receive. For example, if you want to receive messages in a file called

localdirector for message priorities 0, 1, 2, and 3, and you use the default

LOCAL4 facility, the syslog.conf statements would be:

# LocalDirector SYSLOG messages

local4.emerg /var/log/localdirector/localdirector

local4.alert /var/log/localdirector/localdirector

local4.crit /var/log/localdirector/localdirector

local4.error /var/log/localdirector/localdirector

This configuration directs LocalDirector SYSLOG messages to the specified

file. Alternatively, if you want the message sent to the logging host console or

emailed to a system administrator, refer to the UNIX syslog.conf (4) manual

page.

Message Priority UNIX syslog.conf File Keyword

0 — Emergency local n.emerg

1 — Immediate action local n.alert

2 — Critical condition local n.crit

3 — Error local n.err

4 — Warning local n.warning

5 — Notice local n.notice

6 — Information local n.info

7 — Debug local n.debug






Entries in /etc/syslog.conf must obey these rules:

• Comments, which start with the pound (#) character, are only allowed on

separate lines.

• Separate the selector and action pairs with a tab character. Blanks are not

acceptable.

• Ensure that there are no trailing spaces after the file names.

Step 4 Inform the SYSLOG server program on the UNIX system to reread the

syslog.conf file by sending it a HUP (hang up) signal with the following

commands:# cat /etc/syslog.pid

92

# kill -HUP 92

The first command lists the SYSLOG process ID. This number may vary by

system. The second command sends SYSLOG the HUP signal to restart.

See the“syslog” command reference page in Chapter 4, “Command Reference”

for more information.

Configuring SNMP

To configure SNMP, use the following commands:

• Identify the SNMP system location and contact with the snmp-server location and

snmp-server contact commands.

• Designate up to five SNMP management stations that are to receive SNMP traps using

the snmp-server host command.

LocalDirector supports the following mib variables.

mib2.system

mib2.interfaces

mib2.snmp

LocalDirector supports the following SNMP traps. SNMP traps are sent out on both

interfaces.warmStart

linkDown

linkUP

Cisco Syslog Trap






If you are using CiscoWorks for Windows with SNMPc, load the following mibs to see the

traps:

Step 1 Get the files

http://www.cisco.com/public/mibs/v1/CISCO-SYSLOG-MIB-V1SMI.my and

http://www.cisco.com/public/mibs/traps/CISCO-SYSLOG-MIB.traps.

Step 2 Rename the above two files so that they end in ".mib" as follows:

CISCO-SYSLOG-MIB-V1SMI.mib

CISCO-SYSLOG-MIB-TRAP.mib

Note Use the SNMPc to load these mibs. Make sure these mibs are loaded after all the

other mibs otherwise you will get compile errors.

If you are using HP OpenView (UNIX) load the following mibs to see the traps:

Step 1 Get the file http://www.cisco.com/public/mibs/contrib/trapd.conf.

Step 2 As root use the command "/opt/OV/bin/xnmevents -load trapd.conf" to integrate

the Cisco Syslog traps into HP OpenView.

Step 3 Use xnmevents to modify the linkUP, linkDown, warmStart traps so that they are

displayed in the HP OpenView Event viewer. By default the traps are set to"LOG ONLY". If the log option is not changed then you will not see the linkUP,

linkDown, WarmStart traps in your event viewer.

See the “snmp-server” command reference page in Chapter 4, “Command

Reference” for more information.

Requesting the Same Server for Multiple Connections

The sticky command ensures that the same client gets the same server for multiple

connections. This command is used when applications require a consistent and constant

connection to the same server. The sticky command allows you to get back to the same real

server again and retain the statefulness of the system. For example, if a client is completing

an online form, the sticky command ensures that multiple connections are sent to the same

server in order to complete the transaction. Without this command set, each connection

attempt to a virtual server is routedaccording to thepredictor optionselected for that virtual

server, without regard to prior history of the foreign host.






The sticky command does not time how long a client is connected, it times periods of

inactivity. If the sticky command is set to five, and the client is active, new requests from

the client are not sent to another server via load balancing after five minutes. However, if

five minutes of connection inactivity elapse, the requests from the client could be sent to

another real server.

Configuring for Secure Socket Layer Protocol

LocalDirector supports Secure Socket Layer (SSL) protocol; however, it is essential for the

sticky command on the LocalDirector to be set in order for an SSL transaction to occur.The sticky command enables an SSL handshake to occur between the client and server.

This establishes an SSL session which then allows all communication to be encrypted.


The virtual command is used to identify 192.168.1.100 443 as a server accepting traffic on

port 443 (SSL):


The sticky command is used to ensure that requests from the same client will be sent to the

same real server until 10 minutes of inactivity have elapsed:

LocalDirector(config)# sticky 192.168.1.100 443 10

Configuring NT ServersSome webservers (especially those running Microsoft Windows NT 4.0) will continue to

establishconnections to a real servereven though thedaemonor application running on that

port is dead. Use the data command to limit the number of connections sent to a server that

is not sending data.

UDP/Multimedia Applications

LocalDirector does not load balance UDP applications like RealAudio, although

LocalDirector can bridge UDP applications. UDP packets sent to a virtual IP address will

be dropped, and UDP packets sent directly to the real server IP address are bridged.


eff: ex-3--cisco-localdirector

Documents