This document describes changes to features and commands that are different or not described in the Cisco LocalDirector Installation and Configuration Guide (Document Number 78-5192-01).
If an interface failed in a failover configuration, entering the show failover command on the active unit only showed that the standby unit was failed; it did not show the exact failure. The show failover command had to be entered on the failed unit to see the cause of the failure. [CSCdj84478]
For access to customer sites from behind a firewall, passive FTP did not work. Connections could not complete because the source address changed from the clients expected communication address and the firewall was only open to return traffic from the virtual address. [CSCdj61333]
Polling sysUpTime returned 0 instead of the uptime for the hardware. [CSCdj67096]
In a failover configuration, if an interface was pulled (or went down) it would, in some cases, not "auto recover" when the interface was back up. [CSCdj93114]
The high-order byte of the source MAC address of Ethernet packets for all traffic going through LocalDirector is set to zero. This is not a problem for most users since this byte is only set in a FDDI or Token-Ring environment using source route bridging. If the MAC address was changed on the Ethernet device that set this byte, it could cause problems. [CSCdj73694]
For active FTP connections that were being load balanced via a virtual server, the LocalDirector did not translate the DATA connection for connections where the FTP server was not using port 20 as the source port. [CSCdj82574]
In a switched environment, the switch connected to LocalDirector may forget LocalDirector's MAC address in a non-failover configuration. This is because the LocalDirector preserves the source MAC address for all load-balanced packets, and it does not source packets with its own MAC address unless the LocalDirector has a Telnet session or is sending syslog/SNMP messages to a defined server. This causes the CAM table on the switch to not include the LocalDirector's MAC address. [CSCdk02195]
Newer FDDI cards will report information from the show interface command that is counter intuitive. The newer cards report the state of the FDDI ring as "isolated" rather than thru, wrap A, or wrap B. There are two ways to determine whether you have a new or an old FDDI card. The first is through the software. If you use the show interface command, the LocalDirector will respond with "isolated" for the state. The interface will still report a "down" state, but all other states (thru, wrap A, or wrap B) are reported as isolated. This is only a reporting problem, and the card still functions properly. The second way to determine if you have a newer FDDI card is to look at the physical connector in the back. The newer cards are completely black, while the older cards have some metallic color inside. [CSCdk21935]
Packets destined for servers on a different subnet than the LocalDirector traverse the outside Ethernet three times before being forwarded to the appropriate server if directly connected multiple logical subnets are running on the inside interface.
The workaround is to place an additional router behind the LocalDirector to manage the traffic to multiple subnets, and add appropriate route statements to the LocalDirector configuration. [CSCdj69947]
Using the sticky command creates a load inbalance when clients are coming from a site that uses a proxy server to access the Internet. Since sticky only uses the client's IP address for storing the association to a real server, all clients coming from a proxy server get sent to the same real server. A potential workaround is to use a port-bound virtual server for the SSL port and set sticky only for that virtual address. If sticky is being used for regular web traffic, this will not help. [CSCdj81299]
LocalDirector needs to disable the Cisco Syslog MIB, so it will not send traps for every SYSLOG message when an SNMP host is configured. [CSCdj82485]
For Active FTP connections that are being load balanced via a virtual server, the LocalDirector will not translate the DATA connection when the FTP server is not using port 20 as the source port. In most cases, this will not cause a problem; however, if a customer is using a proxy server for FTP, it could use a port other than port 20 for the DATA connection. In this case, the FTP DATA connection will appear to be coming directly from the server instead of the virtual address and packets will not be translated. [CSCdj82574]
If the standby unit is not present when the active LocalDirector is receiving connections in a failover configuration, it will not replicate already established connections to the standby unit when it becomes available. [CSCdk20283]
The entire configuration is read by the configure net command. If a command that is executed changes the system IP address, communication with LocalDirector will be lost and will have to be re-established.
If an interface is secured by the secure command, it may not be possible to communicate with a standby unit from an external device; however, the failover mechanism will work in the event of a failure on the active unit.
The 4-port Ethernet card in the LocalDirector does not autonegotiate, and will not accept the auto option with the interface ethernet command. The ports on the 4-port Ethernet card will default to 100BaseTX. The 10BaseT|100BaseTX|100full options are available, but the auto option is not.
If the peer port autonegotiates, the 4-port interface speed must be set with the 10BaseT or 100BaseTX options; setting it to 100full will confuse the autonegotiation process on the peer port, resulting in unpredictable behavior.
The LED behavior on the 4-port Ethernet interface is different from other Cisco products.
Green - Indicates data transmission activities relative to the amount of traffic.
Flashing amber - Autosensing in progress (even with no configuration and no cable connections).
Steady amber - Active connection (this is normal operation).
Identical LocalDirector units should be used in a failover configuration. For example, a LocalDirector 420 should be used to back up another LocalDirector 420, and each unit must have the same number and type of interfaces.
If failover is configured, use the no interface command to disable unused interfaces. Otherwise, the unused interfaces will be seen as failed and the unit will fail.
The map command has been removed, and configurations that include the map command are not allowed. To upgrade to LocalDirector version 2.1.1, create a new configuration that uses port-bound servers instead.
Use a colon as a delimiter for ports and bind-IDs when defining virtual and real servers.
LocalDirector security features include the following:
Secure Access
LocalDirector can determine how to handle connections based on the source IP address of the client. By using the assign command and the bind-ID on a virtual server, traffic can be directed to a specific location or dropped altogether.
Secure Bridging
Before version 2.1.1, LocalDirector bridged traffic that was not destined for a virtual server. If a real server had a valid registered IP address, clients could access the server through its IP address and bridge directly through the LocalDirector. For security, you can now turn bridging off and not allow direct access to real servers. By using the secure command to turn bridging off for real servers, client traffic must go through a LocalDirector virtual address.
This works with the current failover option to ensure that active connections to a virtual are not dropped in the event of a LocalDirector failover. Before version 2.1.1, the state of client connections to virtual servers was not maintained if a LocalDirector unit failed. Now, connection state can be maintained on a per-virtual basis. This feature is turned on or off for each virtual server with the replicate command.
State information will be maintained on connections for the virtual server, and state information is passed from the active unit to the standby unit via the network (not the failover cable). You can specify which interface will monitor state information, and you can dedicate an Ethernet interface on each LocalDirector to provide state information (on units with three or more interfaces) with the replicate interface command.
Stateful failover is beneficial for applications with a long connection time such as Telnet. It is not recommended for short-lived (and high volume) connections such as HTTP. However, it could be beneficial to have stateful failover turned on when the HTTP connections are utilizing the KEEP-ALIVE option and there is a low volume of HTTP traffic for the virtual server.
LocalDirector version 2.1.1 supports up to 16 interfaces on the LocalDirector 420 and 3 on the LocalDirector 415 and 410. This can be useful in a number of ways. For example:
In some situations, the LocalDirector could have Ethernet-switch-like capabilities, where each individual web server is placed on a separate interface, avoiding the need for a switch between the LocalDirector and the server farm.
If the web farm has web servers and back-end database servers, the web farm could access the database farm through a virtual interface, thus obtaining the benefits of load-balancing and server redundancy from the web servers to the database servers.
Multiple interfaces make Fast EtherChannel possible.
An interface can be dedicated to communicating state information between LocalDirector units by using the replicate interface command. This is useful for stateful failover.
LocalDirector interface numbering has changed, so that the interfaces are numbered from left to right and top down, as shown in the following illustration:
Note If you are upgrading a LocalDirector 415 to version 2.1.1, the numbering of the interfaces will follow the numbering scheme described previously, and the interface numbers will reverse.
Note If you are upgrading a LocalDirector 415 unit, remove all other interfaces before installing 4-port cards. Single-port and 4-port cards cannot be mixed.
Fast EtherChannel is a method of multiplexing 100BaseT interfaces into a single, scalable, virtual channel, and it is currently available on Cisco Catalyst 5000 switches. More than one Fast EtherChannel can be defined on a LocalDirector provided the LocalDirector has more than two interfaces.
LocalDirector real and virtual server (server farm) configuration files can be stored on a TFTP server. The commands associated with TFTP are as follows:
The tftp-server command sets the IP address of the TFTP server, and the directory in which the configuration files are stored.
[no] tftp-server <tftp server ip> <tftp directory>
The configure net command reads configuration information from the TFTP server after the LocalDirector is booted and running. The filename option can be a full path name that is different from the TFTP directory set by the tftp-server command, or it can be a base name in the TFTP directory.
configure net [<filename> [<tftp server ip>] ]
The write net command saves configuration information to the server defined with the tftp-server command. The filename option can be a full path name that is different from the TFTP directory set by the tftp-server command, or it can be a base name in the TFTP directory. On some UNIX servers, the file must be defined before LocalDirector can write to it.
write net [ [<tftp server ip>]<filename> ]
The boot config command is stored in Flash memory, and will enable the LocalDirector to get the server farm configuration via TFTP at boot time. If the boot config command is active, the write floppy|memory command will only save the tftp-server, configure net, and boot config commands in the system configuration. The filename option must be a full path name.
[no] boot config <filename> <tftp server ip>
The boot image command enables booting from a remote image (version of LocalDirector software) on a TFTP server. The filename option must be a full path name.
The static command enables the source IP address of the outbound packet to be translated to a virtual address for connections initiated from a real server.
This feature allows clients that reach a particular virtual address to get load balanced to different real servers according to the source IP address of the client. That is, different clients going to the same virtual server can be directed to different real server bindings for the same virtual address. This is accomplished by extending the concept of a virtual to include a bind-ID. The bind-ID is used with the assign command to associate a client IP address with a specific virtual server.
There are many possible uses of this feature, including:
Grades of Service
You can assign known client IP addresses to a collection of more powerful servers in order to obtain faster service for them.
Special Services
You could take client IP addresses known to be a part of your company to an internal page, but send unknown clients to a generic home page.
Not Welcome Mats
You can assign "problem" client IP addresses to a real machine that serves a page indicating that the user is not welcome to your site.
Previously, commands that referenced virtual servers and real servers could reference a machine as the IP address and an optional space-separated port number. Real servers and virtual servers are now described as an IP address followed by a colon, followed by the port number. Virtual servers can include an optional colon-separated bind-ID. When an existing configuration is upgraded to version 2.1.1, a colon will be used as a delimiter automatically.
The default bind-ID is 0, and any client IP address not configured with the assign command will be directed to the default bind-ID of 0. If you do not create the default bind-ID version of the virtual server (a virtual server with a bind-ID of 0), then only IP addresses configured with the assign command will be allowed in, and all other requests will be blocked. This can be used as a powerful security feature.
The LocalDirector now performs a CRC (cyclic redundancy check) on the software image. If the LocalDirector is booted from a diskette or TFTP file with a bad image, it will return an error message and hang.
Table 1 lists commands that are new or changed in version 2.1.1. For detailed information about these commands including syntax, usage guidelines, and examples, refer to the Cisco LocalDirector Installation and Configuration Guide, Version 2.1.
The replicate command enables stateful failover, and the replicate interface command sends replication data to the standby unit via a dedicated interface.
Cisco 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.
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 ccohelp@cisco.com. For additional information, contact ccoteam@cisco.com.
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 tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or csrep@cisco.com
Cisco documentation and additional literature are available on 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 in the toolbar and select Documentation. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
