Guest

Cisco Catalyst 2800 Series Switches

FDDI Version 1.19 Release Notes

  • Viewing Options

  • PDF (63.4 KB)
  • Feedback
78-3713-02

Table Of Contents

Release Notes for FDDI Version 1.19

Important Notes

Upgrading FDDI Module Firmware with Xmodem

Version 1.19

Module Stops Forwarding from FDDI to Ethernet

Module Does Not Forward Traffic Under Heavy Loads

Version 1.14

Version 1.13

Loss of FDDI/Ethernet Connectivity

Loss of FDDI/Ethernet Connectivity for 15 Seconds

Poor FDDI/Ethernet Performance

Elastic Buffer Error Counter Goes up During Reconfiguration

FDDI Module Disconnects Itself Permanently from FDDI Network after Beacon and Trace Conditions

Banyan Vines for Translational Bridging Not Supported

Version 1.11

Version 1.10

IPX Communication Packets Between Two FDDI IPX Hosts Are Flooded to the Ethernet Ports

The FDDI Module Causes a Network Management Station to See Incorrect FDDI Topology Map.

Version 1.08

Version 1.07

An Optical Bypass Is Not Detected

IP Communication Between Ethernet and FDDI Hosts Might Not be Established

Version 1.06

Version 1.05

Cisco Connection Online


78-3713-02

Release Notes for FDDI Version 1.19


May 11, 1998

These release notes describe the changes made to the FDDI module firmware between versions 1.14 and this version, 1.19. It also contains a log of the changes made to the FDDI module firmware since its initial release.

FDDI modules can be used with the Catalyst 2800, Catalyst 2820, EtherSwitch 1400, and EtherSwitch 1420 switches. The documentation for FDDI modules is as follows:

Catalyst 2800 Modules User Guide

Catalyst 2820 Modules User Guide

EtherSwitch 1420 Modules Installation Guide

EtherSwitch 1400 Modules User Guide

Important Notes

Upgrading FDDI Module Firmware with Xmodem

When performing an Xmodem upgrade of FDDI module firmware, set the Xmodem timeout value to 15 seconds or longer. Certain communications packages, such as Procomm Plus for Windows, version 1.01, set the Xmodem timeout value to less than 15 seconds; this could cause the timeout to fail.

Version 1.19

This version resolves the problems described in the following sections.

Module Stops Forwarding from FDDI to Ethernet

After long periods of significant traffic flowing in the FDDI-to-Ethernet direction, the FDDI module can gradually loose buffers and stop forwarding this traffic. Traffic flowing in the Ethernet-to-FDDI direction is not affected.

A software fix has been implemented for this problem. Customers who notice this problem should upgrade to FDDI module software version 1.19. (CSCdj62826)

Module Does Not Forward Traffic Under Heavy Loads

Under certain conditions the FDDI module is unable to forward frames between FDDI and Ethernet. Version 1.19 is the first version to fix this problem. Customers who experience this problem should upgrade their module firmware to version 1.19. (CSCdj01039)

Version 1.14

This version supports RFC 1191 Path MTU Discovery. When the FDDI module cannot forward an IP datagram because it exceeds the MTU of the next-hop (1500 bytes) and the Don't-Fragment bit is set, the FDDI module returns a Destination-Unreachable message to the datagram source. The message code is fragmentation needed and DF set. The Next-Hop MTU is set to 1500 in the ICMP header.

For this release, the source IP address is set to 0 in the ICMP message. This does not affect the operation of the MTU Discovery.

Version 1.13

This release fixes the problems described in the following sections.

Loss of FDDI/Ethernet Connectivity

If an FDDI network has IP frames with an IP datagram larger than 1500 bytes and there is at least one error in the IP header or the Don't Fragment bit is set to drop oversized frames, the FDDI module might reset. FDDI/Ethernet connectivity is lost for about 15 seconds. This condition might also result in the loss of Ethernet/FDDI connectivity until the FDDI module is manually reset.

Loss of FDDI/Ethernet Connectivity for 15 Seconds

If an FDDI network has IP frames with the actual size of the FDDI frame larger than 1525 bytes (including FC and FCS) and the Total Length field in the IP header is equal to or less than 1500 bytes, the FDDI module resets. FDDI/Ethernet connectivity is lost for about 15 seconds.

Poor FDDI/Ethernet Performance

When the traffic on all the Ethernet ports is less than 10 packets per second, the switch might perform poorly after a few days. This light traffic causes a loss of FDDI/Ethernet connectivity or extremely poor FDDI/Ethernet performance. The switch needs to be rebooted to resume normal operation.

Elastic Buffer Error Counter Goes up During Reconfiguration

Elastic Buffer Error happens when a fiber-optic cable is connected to an inactive port on the FDDI module or when there is a reconfiguration. This is normal behavior. The Elastic Buffer Error counter should not increment because the port is inactive. The Elastic Buffer Error counter should only increment if the error occurs on an active port.

FDDI Module Disconnects Itself Permanently from FDDI Network after Beacon and Trace Conditions

When there is a Beacon or Trace condition on a FDDI network and the Requested Target Token Rotation Time of the FDDI module's upstream neighbor is better, the FDDI module detects a duplicate MAC address condition incorrectly and disconnects itself from the network. The FDDI module needs to be rebooted to resume normal operation.

Banyan Vines for Translational Bridging Not Supported

Banyan Vines requires a translational bridge to translate FDDI SNAP frames with 0x80C4 as the protocol type to an Ethernet II frame with 0x0BAD as the protocol type. The FDDI module does not perform the translation.

Version 1.11

This release fixes the following problem.

When a source routing frame is received on FDDI, the FDDI module might reset itself or stop receiving user data frames from FDDI.

Version 1.10

This release fixes the problems listed in the following sections.

IPX Communication Packets Between Two FDDI IPX Hosts Are Flooded to the Ethernet Ports

The FDDI module learns the source MAC address of an IPX frame only if the destination MAC address of the frame is unknown.

Assume there are two IPX stations with MAC addresses A and B on the FDDI network. When A sends a frame to B, the FDDI module learns source address A and forwards the frame to the Catalyst 2820 switch. The switch learns that address A is on the FDDI network. When B sends a frame to A, the FDDI module does not learn the address B, as the destination address A is known. As A is known to be on the FDDI network, the frame is dropped and not forwarded to the Catalyst 2820 switch.

When A sends a frame to B, the FDDI module does not know where B is and the frame is forwarded to the switch. As the switch does not know where B is, the frame is flooded to all the Ethernet ports.

All frames sent to B from A are flooded to all Ethernet ports.

The FDDI Module Causes a Network Management Station to See Incorrect FDDI Topology Map.

The FDDI module does not set the A (Address Recognized) and C (Copied) symbols in the frame status for frames that have a broadcast address (FF-FF-FF-FF-FF-FF) as their destination address.

Version 1.08

This release fixes the following problem: FDDI module performance drops when a few thousand error-packets-per-second, intermixed with good frames, are forwarded from Ethernet ports to the FDDI network.

Version 1.07

This release fixes the problems described in the following sections.

An Optical Bypass Is Not Detected

The FDDI module does not detect an optical bypass if it is inserted after the FDDI module becomes active.

IP Communication Between Ethernet and FDDI Hosts Might Not be Established

When an IP ARP packet is received from the FDDI network, the hardware type is not translated from 6 to 1 before the packet is forwarded to Ethernet. Some older IP implementations on Ethernet might not support the hardware type of 6 and drop the packet.

Version 1.06

This release fixes the following problem: the FDDI module power-on self-test fails when the Catalyst 2820 receives more than 60 packets-per-second of broadcast packets.

Version 1.05

This is the first release of the FDDI module.

Cisco Connection Online

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:

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 cco-help@cisco.com. For additional information, contact cco-team@cisco.com.


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 tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.