May, 1998
This document describes changes to features and commands that are different or not described in the Cisco LocalDirector Installation and Configuration Guide, Version 1.6.3 (Document Number 78-3456-05).
The following sections are included:
- "Bug Fixes for Version 1.6.8," page 2
- "Notes and Caveats," page 2
- "LocalDirector Platforms," page 3
- "Documentation Errata," page 8
- "Known Bugs," page 8
- "Bug Fixes in Version 1.6.7," page 8
- "Bug Fixes in Version 1.6.6," page 9
- "Bug Fixes in Version 1.6.5," page 9
- "Bug Fixes in Version 1.6.4," page 10
- "Bug Fixes in Version 1.6.3," page 10
- "Bug Fixes in Version 1.6.2," page 10
- "Cisco Connection Online," page 11
- "CD-ROM Documentation," page 12
If an interface on a 4-port interface card was set to 100half and an interface for the other side was set to auto with the interface ethernet command, the link status would remain Down on the LocalDirector side unless the network cable was unplugged and then plugged back in to the unit. If both sides were set to the same speed, everything worked fine. [CSCdk08440]
- 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).
- The map command will be removed in a future release of LocalDirector. The ability to define port-bound servers with the real and virtual commands has eliminated the need for the map command. In version 2.x, configurations that include the map command will not be allowed.
- Identical LocalDirector units are required for failover configuration.
- The primary and secondary LocalDirector units in a failover configuration 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 a previous version.
- If you configure failover, the configuration replication feature will overwrite the host name of the active unit in the configuration of the standby unit. Therefore, you cannot use the hostname command to configure each unit to have a different name. Do not use the host name in the command line prompt as a means of determining which LocalDirector unit you have accessed.
- 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
- 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 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.
- 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.
- 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 the10BaseT or 100BaseTX options; setting it to 100full will confuse the autonegotiation process on the peer port, resulting in unpredictable behavior.
There are three LocalDirector platforms - the new LocalDirector 420, the new LocalDirector 410, and the original LocalDirector. The original LocalDirector (CA-LDIR) is now referred to as the LocalDirector 415. See the Cisco Product Bulletin at http://www.cisco.com/ld for more information about the LocalDirector 420 and 410.
LocalDirector version 1.6.5 and later supports the 4-port Ethernet interface in the LocalDirector 420. The ports are numbered 0 to 3, with port 0 on the top of the interface and port 3 on the bottom. Only port 0 and port 1 are enabled at this time. The other two ports are disabled until version 2.x. It does not matter which port connects to the client network and which connects to the real server network. Multiple 4-port cards will be supported in version 2.x.
Note Ports 2 and 3 on the LocalDirector 420 are disabled until version 2.x.
The front panel of the LocalDirector 420 is shown in Figure 1. Note that the diskette drive, interfaces, console port, and failover port are accessed from the front panel.
Figure 1: LocalDirector 420 Front Panel
The back panel of the LocalDirector 420 is shown in Figure 2. The power cord receptacle and power switch are located at the back of the unit.
Figure 2: LocalDirector 420 and 410 Back Panel
The front panel of the LocalDirector 410 is shown in Figure 3:
Figure 3: LocalDirector 410 Front Panel
The LocalDirector 410 back panel is the same as the LocalDirector 420, shown in Figure 2.
LocalDirector version 1.6.5 and later supports two of the 10/100 interfaces on the LocalDirector 410. The ports are numbered 0 to 2 from the left to the right, and port 2 on the third interface is disabled until version 2.x.
Note Port 2 on the third interface of the LocalDirector 410 is disabled until version 2.x.
Version 1.6.x software is supported on the LocalDirector 415.
Note In version 1.6.5 and earlier, interfaces on the LocalDirector 415 are read right to left, which is the opposite of the LocalDirector 410 and 420. In LocalDirector version 2.x, all interfaces will be numbered left to right, top to bottom. Interface numbers of existing units will change to conform to this numbering scheme.
Rackmount brackets are optional on the LocalDirector 420 and 410. To attach the rackmount brackets, refer to Figure 4:
Figure 4:
Attaching Rackmount Brackets
Table 1 shows the interfaces that are supported on the LocalDirector platforms:
Table 1: Supported Interfaces by Platform
| Platform
| 4-Port 10/100 Ethernet Card
| 1-Port 10/100 Ethernet Card
| FDDI
|
|---|
| LocalDirector 420
| 1 supported in version 1.6.5 and later, up to 4 in version 2.x
| not supported
| 2 supported (multimode, dual-attached, SC connectors)
|
| LocalDirector 415 (original platform, CA-LDIR)
| 1 supported in version 2.x
| 2 supported in version 1.6.5 and later, 3 supported in version 2.x
| 2 supported (multimode, dual-attached, SC connectors)
|
| LocalDirector 410
| not supported
| 2 supported in version 1.6.5 and later, 3 supported in version 2.x
| not supported
|
4-port Ethernet cards are supported on the LocalDirector 420, and the LocalDirector 415 will support one 4-port Ethernet card in version 2.x. The LocalDirector 410 does not support 4-port Ethernet.
The LocalDirector interface numbering scheme will change with the introduction of 4-port Ethernet cards. The 4-port interfaces on the LocalDirector 420 are numbered left to right, top to bottom.
Interfaces on the LocalDirector 415 are numbered right to left, bottom to top. Interface numbering on existing LocalDirector 415 units will remain the same in version 1.6.x, but will change to left to right, top to bottom in version 2.x.
Note Interface numbering on the LocalDirector 415 will remain the same in version 1.6.x, but will reverse when upgraded to version 2.x.
Each interface port has two LEDs, one amber and one green. Table 2 explains the states of the LEDs on the 4-Port interface cards.
- 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).
- The interface ethernet 0 auto command causes the amber LED to blink continually when the link is not up, and interface ethernet 0 [10baset|100basetx|100full] shuts off the amber LED when the link is not up.
Table 2: 4-Port Interface LEDs
| LED
| LED State
| Indication
|
|---|
Green
| off
| No data transmission.
|
| on
| Steady data transmission.
|
| flashing
| Intermittent data transmission.
|
Amber
| off
| Disabled or unused. If the interface was configured with the 10baset, 100basetx, or 100full options, the link is not up yet.
|
| on
| The connection is active.
|
| flashing
| Autosensing. If the interface was configured with the auto option, the link is not up yet.
|
Note The LED behavior on the 4-port Ethernet interface is different from other Cisco products. Use this information to determine if the LED activity indicates normal interface operation.
- The 4-port Ethernet interface card will not accept the auto option with the interface ethernet command, and will return the following error message:
ERROR: this port does not have autonegotiation capability.
- 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 the10BaseT or 100BaseTX options; setting it to 100full will confuse the autonegotiation process on the peer port, resulting in unpredictable behavior.
The single-port card will autonegotiate, but your network interface must support auto-detection.
Note The 4-port interface will not "autosense" to full duplex. This will cause a problem if the LocalDirector interface is at half duplex and is connected to a switch on the other end trying to do full duplex.
The configuration example for Secure Socket Layer Protocol in Chapter Three, "Configuring LocalDirector," of the Cisco LocalDirector Installation and Configuration Guide, Version 1.6.3, incorrectly uses a real server IP address with the sticky command. The example should read as follows:
The virtual command is used to identify 192.168.1.100 443 as a virtual server accepting traffic on port 443 (SSL):
LocalDirector(config)# virtual 192.168.1.100 443
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
- Polling sysUpTime on LocalDirector 1.6.x returns "0". [CSCdj67096]
- 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. [CSCdj61333]
Note The only time this could be a problem is if you use unregistered IP addresses on real servers. The client cannot communicate directly with a real server that has an unregistered IP address across the Internet.
- If a user at the LocalDirector console entered the show process command, and a Telnet user entered the show memory command while the console user was in pager mode, the LocalDirector would crash. [CSCdk03242]
- A LocalDirector 410 running software version 1.6.6 will lock-up after several hours of use. This is attributed to the third network interface that is in the unit, which is not used in version 1.6.6. The third interface was allocating resources and never releasing the resources, which led to the unit being unable to work. [CSCdk02193]
- LocalDirector with FDDI interfaces truncated packets greater than 4096 bytes.[CSCdj93248]
- If the sticky command was used for more than one virtual on the same LocalDirector, a client (foreign IP) would not get back to the same real server. Now, if the client is accessing two virtual servers with sticky set, the information stored on LocalDirector will be updated on a per client, per virtual server basis instead of just a per client basis. [CSCdj86527]
Cisco LocalDirector version 1.6.7 included the following feature change:
- The 4-port Ethernet interface card will not accept the auto option with the interface ethernet command, and will return the following error message:
ERROR: this port does not have autonegotiation capability.
- 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 the10BaseT or 100BaseTX options; setting it to 100full will confuse the autonegotiation process on the peer port, resulting in unpredictable behavior.
- It is possible for LocalDirector versions 1.6.3, 1.6.4, and 1.6.5 to get a watchdog timeout, which will cause the unit to reboot. The LocalDirector will hang for 5 minutes before the reboot happens. This was caused by a reassigned connection due to a "no answer" from the real server for a new connection coming in to a virtual machine. [CSCdj71314]
- The route command was not executed on reboot of the LocalDirector unit. The route command was saved in the flash configuration, but not executed on reboot.[CSCdj75484]
- The delay command was expecting an extra argument on the command line. [CSCdj76975]
- SNMP configuration information was not saved with the write memory command, and that part of the configuration was lost on reboot of the LocalDirector unit. [CSCdj76977]
- Static ARPS were not saved with the write memory command, and that part of the configuration was lost on reboot of the LocalDirector unit. [CSCdj76978]
- Use of the delay command caused connections in LocalDirector memory to be timed out instead of immediately being removed from memory as soon as the connection ended. If the delay feature was enabled and a client reused the same port for another connection while LocalDirector still had the connection in memory, the unit would reboot. [CSCdj76979]
- With a LocalDirector connected to 10BaseT hubs on both sides, one interface would stop receiving traffic and require a reboot to make it receive traffic again. This was caused by a documented bug in the Intel NIC that is used in the LocalDirector. The documented bug states that it is possible for an interface to stop receiving traffic and suggests a workaround to include if the problem occurs. The Intel device driver now includes this workaround. [CSCdj76980]
Note This problem seems much more prevalent on older Intel NICs, and has only been seen twice with a LocalDirector connected to 10BaseT hubs.
- When connections were reassigned by LocalDirector (for example, a real server did not answer a SYN packet or responded with TCP RST), sticky command information was not being updated for the client. Thus, the client's connections would not work if a stateful protocol (such as SSL) was being used. [CSCdj79643]
- There was a bug in the configuration replication feature of LocalDirector where the enable password was not replicated to the standby unit. The enable password is now handled correctly during configuration replication. [CSCdj67564]
- Under heavy traffic loads, the LocalDirector would hang and one or both interfaces showed a state of "Line Protocol UP, Interface DOWN." [CSCdj62498]
- In version 1.6.4, if a client responded with a TCP RST/ACK when a connection was closing, the LocalDirector would reboot. [CSCdj67572]
- Previously, the no snmp-server command would remove all SNMP information from the configuration. Now you must enter the command option associated with the part of SNMP that you want to remove. For example, the no snmp-server location command will remove the text string identifying the location of an SNMP server, but not the IP address of the server. [CSCdj67573]
- When the LocalDirector was polled with a MIB browser, it would respond with "Cisco Firewall" for the sys.descrip and sys.name MIB types. It now responds correctly with
"Cisco LocalDirector." [CSCdj67574]
- When communicating with LocalDirector, if a user connects to a port that is not available, the LocalDirector generates a TCP RST, which is correct. However, there was a bug in the generation of the TCP RST that caused the LocalDirector to reboot or exhibit erratic behavior. [DDTs defect number not available.]
- There was a bug in SYSLOG when two users used the show syslog command at the same time with paging turned on. The second user to continue on paged output would reboot the LocalDirector. [CSCdj53491]
- If a lot of SYSLOG messages were generated and output was directed to the console, it would cause the LocalDirector to crash. [DDTs defect number not available.]
- 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. [DDTs defect number not available.]
- LocalDirector now supports fragmented packets from real servers. Fragmented packets to virtual servers have been supported since version 1.5. [CSCdj33094]
- SNMP auto discovery no longer causes LocalDirector to crash. [DDTs defect number not available.]
- The FDDI interface option was broken in version 1.6.2, but is fixed in version 1.6.3. [DDTs defect number not available.]
- The no option for the sticky command was removed in version 1.6.2, but it is included in version 1.6.3. [DDTs defect number not available.]
- 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. [DDTs defect number not available.]
- The SNMP messages "LocalDirector booted" and "SNMP warmstart" are now sent. [DDTs defect number not available.]
- 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. [DDTs defect number not available.]
- 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. [DDTs defect number not available.]
- LocalDirector correctly stores static ARPs in the configuration. [DDTs defect number not available.]
- 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. [DDTs defect number not available.]
- Static routes are no longer shown twice with the show route command. [DDTs defect number not available.]
- 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. [DDTs defect number not available.]
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.
You can access CCO in the following ways:
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 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 in the toolbar, select Documentation, and click Enter the feedback form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.
