These Release Notes provide specific information regarding this release of the Cisco Catalyst 2600 Token Ring Switch. These Release Notes document important operating environment considerations and known problem areas. References to the User Guide refer to the "Catalyst 2600 Token Ring Switch User Guide" (part # 78-3209-01) shipped with the Catalyst 2600.
 | Caution If your Catalyst 2600 is currently at Release 2.x.x, Release 3.2.3 of the Catalyst 2600 software must be downloaded to your switch using the serial port only. You cannot use TFTP to download this release of software. See your Catalyst 2600 Token Ring Switch User Guide for information about how to perform a serial port download. |
This section describes any known problems, anomalies, or design points.
The ARI and FCI status indicator bits are not set for frames that include an RI field. Customers with applications that depend on A and C bits should contact their vendor for information on whether or not a patch/fix is available.
Symptoms of possible ARI/FCI problems are:
- End systems fail to connect when attached to the switch but succeed when connected to the same MAU.
- Excessive soft error reports.
The following is a list of drivers known to be affected by this problem. This list is provided for your information only and is not intended to be a complete list of affected drivers.
| Driver Name
| Product
| Fixed Level
|
|---|
| NETBEUI.OS2
| OS/2 NetBIOS
| 5.00.0
|
| DXMCOMOD.SYS
| DOS LSP (and DXMC1MOD)
| 1.38p
|
| DXMJ0MOD.SYS
| DOS JetBEUI
| 1.38p
|
IFNDIS.SYS
| TCP/IP v2.0 for OS/2
| APAR pn77766
|
| TCP/IP v3.0 for Warp Connect
| APAR ic11795
|
| LANDD.OS2
| OS/2
| 5.00.02
|
| LANDD.NIF
| OS/2
| 5.00.02
|
| NET.EXE
| DLS (DOS LAN Services)
|
|
A package called TRDRVFIX.EXE includes ALL the updated IBM drivers. This package is available from the following sources:
- IBM PC. Co. BBS (919) 517-0001
- The web site is www.pcco.ibm.com
- Download the file from the Networking Environment Support Team (NEST) BBS at (919) 543-2307, for 28.8 (919) 543-5570.
For IBM technical support: 1-800-426-7299 Call path 4, 6, 3
On some emulators, console sessions through the serial port may drop after an extended period of time, if hardware flow control has been enabled on the switch. The connection is usually re-established by disconnecting and reconnecting the serial port cable. To avoid this problem, * be sure the hardware flow control is disabled in the switch's Serial Link Configuration and that your emulator configuration conforms to the set up recommendations that are documented in the Catalyst 2600 Token Ring Switch User Guide.
The SRB must be in the disabled state when the bridge number is changed to ensure the proper functioning of SRB spanning tree.
The Token Ring adapter for the IBM 9221 (ES/9000) Processor will not open when directly attached to a Catalyst 2600 port. You must use a multistation access unit or a controlled access unit.
This release of the Catalyst 2600 software does not support the capability of configuring a port to be full-duplex (FDX) only. All ports support the option (as defined by the 802.5R IEEE committee) of FDX protocol with an automatic drop-back to half-duplex (HDX) support. If a directly attached station attempts to open in HDX mode, the Catalyst 2600 ports will allow this and make the connection in HDX mode.
The maximum frame length supported by the Catalyst 2600 is 4540 bytes (including the Frame Control [FC] and the Frame Check Sequence [FCS] characters). Be sure to configure all network software, interconnecting products, workstations, and user applications to send frames no larger than 4540 bytes.
- In cut-through mode, the Catalyst 2600 truncates frames larger than 4540 bytes and adds an abort sequence at the end. Typically, if frames larger than 4540 bytes are sent, a network manager will detect the abort sequences from the Catalyst 2600.
- In store-and-forward mode, switch ports will drop larger frames and generate a soft error on that port's LAN segment. The Catalyst 2600 provides statistics regarding frames that are too long.
-
Ports can stop receiving frames under high traffic conditions. When this happens, Spanning-Tree Protocol may not function correctly, causing loops to form. The port hang conditions can be detected by monitoring the Frames Received counter on the Switch Statistics menu under Status/ Statistics. The port hang conditions can be cleared by using the Port Reset function on the Reset/Diagnostics menu.
If you fail to upgrade the port solo code when you update to this release level, all of your ports will be placed into Store and Forward mode to help the main code coexist with the old port solo code.
If you want to migrate from a Release 3.X level of the code back to a Release 2.X level of the code, you must do the following:
- Ensure that you have the configuration of the switch on hard copy because a later step will clear the configuration.
- Load all three code images (solo, main, and boot)
- After all of the code is loaded and you have reset the switch, then go the Reset/Diagnostic panel and Clear Non-Volatile RAM. This will reset the configuration files to the Release 2.X level defaults. If you do not clear NVRAM, the configuration files will still be for Release 3.X and your results will be unpredictable.
MIB browsers display errors of OCTET STRING objects. Under certain conditions, some MIB Browsers including the IBM NetView/6000 MIB Browser, will incorrectly interpret the value of an OCTET STRING. The OCTET STRING may be printable ASCII characters. For example, the hexadecimal value of "41" is displayed as an "A".
This can affect the following objects:
- 8272 Private MIB Octet Strings
- ibm8272TsTrapRcvrDmns
- ibm8272TsPortStnAddress
- ibm8272TsOptPortStaVal
- ibm8272TsDmnPorts
- ibm8272TsDmnBaseBridgeAddr
- ibm8272TsDmnStationAddress
- ibm8272TsDmnStationTraffic
- ibm8272TsOptDmnStaVal
- ibm8272TsPipePorts
- ibm8272TsFilterStationAddress
- ibm8272TsFilterPorts
- ibm8272TsFilterMask
- ibm8272TsUFCType
- DTRC MIB Octet Strings
- dtrConcentratorAddress
- dtrCRFPortMask
- dtrCRFMacAddress
- dtrCRFSpTreeDesignatedRoot
- dtrCRFPortSpTreeDesignatedPort
- dtrCRFPortSpTreeDesignatedRoot
- dtrCRFPortSpTreeDesignatedBridge
- dtrCRFPortSpTreeDesignatedPort
- dtrFdbDynamicAddrStnAddress
- dtrFdbDynamicRDRouteDesc
- dtrExSrbStpAddress
- dtrExSrbStpDesignatedRoot
- dtrExSrbPortStpDesignatedRoot
- dtrExSrbPortStpDesignatedBridge
- RFC1213 Octet Strings
- atPhysAddress
- ipNetToMediaPhysAddress
- RFC1231 Octet Strings
- dot5UpStream
- dot5Functional
- RFC1493 Octet Strings
- dot1dStpPortDesignatedPort
- dot1dBaseBridgeAddress
- dot1dTpFdbAddress
- dot1dStpDesignatedRoot
- dot1dStpPortDesignatedRoot
- dot1dStpPortDesignatedBrid
- RFC1573 Octet Strings
- Discovery MIB Octet Strings
- announceAddress
- mapAddress
Most SNMP MIB browsers cannot create a new MIB table entry. This can impact the following tables:
MAC filter entries can be created using a native SNMP SET request, a network management application, a console session, or a Telnet session.
When IEEE 802.1d spanning tree is active, a port within that domain will require several seconds to make the transition from the blocking state to the forwarding state when the port is initially activated (e.g., joins an existing ring or activates a dedicated link). Some client or server applications may attempt to establish session activity during this time, resulting in error messages indicating a connection failure. These applications should be configured to wait at least 30 seconds after the LAN link is active before attempting to establish session activity. This delay can be reduced by modifying the 802.1d spanning tree default parameters.
The dtrc.mib DESCRIPTION for the dtrCRFPortEnable object should be changed to: The enable/disable status of the CRF Port. This control can be used to disable a port.
- When you WRITE, the configuration is changed.
- When you READ, the data returned is the current operational state of the CRF Port, not the configuration.
This section provides information about changes made and problems fixed in each release of the Catalyst 2600. The most recent release is listed first.
- A full-duplex fiber switch-to-switch connection may not reconnect when one of the switches is reset with diagnostics. A reset of the adapter end of the fiber was required to connect successfully.
- If the switch was configured to have a secure source for a port and then allowed one source address to filter to all ports, that source could not communicate with the switch.
- ARE frames were not forwarded through the internal SRB when an internally bridged domain was not physically connected to its Token Ring segment in a network with redundant source-route paths.
- If a port in a bridged domain was used as a probe port and then the probe port was removed (deconfigured), normal traffic would not be bridged to that port until the port or the switch was reset.
- Some minor issues with port security and filtering have been resolved.
- The problem with migrating from release 3.11 to a newer release has been resolved.
- In certain conditions with Spanning Tree Protocol 802.1d configured, a port could forward frames inappropriately, resulting in a potential loop in the network.
- Previously, the following counters in the Token Ring RMON MIB (RFC1513) were always zero:
- tokenRingMLStatsRingPurgeEvents
- tokenRingMLStatsRingPurgePkts
- tokenRingMLStatsBeaconPkts
- tokenRingMLStatsClaimTokenEvents
- tokenRingMLStatsClaimTokenPkts
- tokenRingMLStatsRingPollEvents
- tokenRingMLHistoryRingPurgeEvents
- tokenRingMLHistoryRingPurgePkts
- tokenRingMLHistoryBeaconPkts
- tokenRingMLHistoryClaimTokenEvents
- tokenRingMLHistoryClaimTokenPkts
- tokenRingMLHistoryRingPollEvents
- The search option on the Message Log Information screen would not work for message numbers over 1000.
- After using <ctrl-n> or <ctrl-b> from a serial port console session, "Non-Token-Ring Ports Menu..." option could not be accessed from a telnet session.
- "Domain Route Descriptor Table..." option would, in certain situations, indicate that the table is empty, when in fact entries did exist.
- Entries may be displayed on the "Logical Ports" panel for the "Master Address Table" even if there are no logical ports active for the selected physical port.
- Switch Resets - The following problems could lead to a switch reset and have been fixed in this release:
- Some telnet sessions were not terminated correctly, which could have led to a switch reset at a later time.
- A problem with Token Ring port initialization could lead to a box reset or box hang (all port leds turned off for example).
- Displaying a message block to the console while on an auto- refresh screen could lead to a box reset.
- In some cases, a Token Ring port reset and initialization would not complete. The LEDs for that port would be out, and it would not connect.
- A Token Ring port initialization problem could lead to a port reset with the message MPC Initialization failed.
- A problem with phantom voltage detection could lead to a port reset for a Token Ring port that is running in PORT mode.
- Serial port code download via the system request button could fail intermittently. This problem only occurred when the system request button was pressed during a switch boot.
- A continuous ping of the switch could stop after a domain change.
- Changes were made to make NVRAM management more efficient in order to minimize the risk of running out of space. This problem could have led to an inability to change the switch configuration.
- When the message log wraps, messages that were written to the log could be displayed with a third line of information from an old message.
- Port Resets - These problems are exasperated by Token Ring errors on the segments connected to the switch. The port handling code has had a number of improvements in this release.
- HI Q not empty message - This condition has been corrected so that it will no longer result in a port reset.
- LAP Access Violation - This problem was an incorrect handling of the communication between the port code and the I960 processor code. This would result in an Adapter check and a port reset. This fix corrects some conditions that where still remaining after the previous maintenance level.
- Switch Resets - There have been a number of different problems that have been fixed in this release that could lead to a switch reset. Some of these switch reset problems are listed below:
- Invalid Memory Access condition leading to a box reset. This problem was caused by an uninitialized variable.
- An Invalid Port Access condition can lead to a box reset. Some invalid port access conditions have been resolved. There are still some other Invalid Port Access conditions under investigation.
- If a port connection was established during Congestion control on a switch then the switch could reset.
- A timing window existed such that the program stack (memory) could get corrupted leading to a box reset. Changes have been made to eliminate this timing window.
- A problem that resulted in a "Transmit Buffer Corruption" message during boot initialization has been corrected.
- A problem with TokenChannels existed such that traffic may only flow in one direction across the TokenChannel for a specific address. The result of this problem would be a station on one side of the TokenChannel would not be able to communicate across the TokenChannel. The symptom a customer might see is that clients could contact a sever across a TokenChannel but, the server could not respond to the clients. This problem was with a specific address however, if that address was a Route Descriptor then the impact would be for all addresses that have that route.
- A timing window existed such that the switch could have problems handling a spanning tree topology change. This problem would result in the switch constantly removing all of the known addresses from the port address table and communications through that port would be inconsistent.
- A timing window existed such that the when a port is reset it could enter the Spanning Tree Listening state (LSN) and not transition to the Spanning Tree Forwarding state (FWD). This would result in no traffic flowing through that port.
- Receive hangs - This problem is where a port will stop receiving frames from the locally attached segment. A fix has been made to the transmit hang correction code that lead to this receive hang condition.
- A function to search the message by message number has been added. If a message number higher than any existing number in the log is entered the latest message will be shown. If a message number of 0 is entered then the top of the message log will be shown.
- The Type field on the message log screen should now correctly show an "F" for fatal fault error messages.
- The edit checking for the Switch Maximum Message Age field on the Transparent Spanning Tree Configuration screen has been changed to take into account the condition if there is only one valid value instead of a range of valid values.
- The Source Route Configuration screen has been changed to support domain names of the length that can be entered on the Domain Configuration screen.
- An informational message has been added to the message log when a switch is reset to indicate when the event happened and the main code level at the time of the reset.
- Some alignment problems on the Master Route Descriptor Table screen as well as some inconsistent column headings have been fixed.
- Port Resets - These problems where exasperated by Token Ring errors on the segments connected to the switch. The port handling code has had large number of improvements in this release.
- MPC Init Failures - This situation should be eliminated.
- MPC HP Config Channel command failed - The cause of this problem has also been eliminated.
- Adapter Checks - There where a couple of ways that the adapter checks could appear. One of the reasons was a false Transmit Port Hang detection and subsequent recovery attempt could lead to an Adapter Check. It was also possible to get an Adapter Check when the LAP Access Violation problem occurred.
- LAP Access Violation - This problem was an incorrect handling of the communication between the port code and the I960 processor code.
- Switch Resets - There have been a number of different problems that have been fixed in this release that could lead to a switch reset.
- Some of these switch reset problems are listed below:
- An Invalid Port Access condition can lead to a box reset. Some invalid port access conditions related to the access of adapter memory have been resolved. There is still some Invalid Port Access conditions under investigation.
- During a boot-up with diagnostics if a port was disabled by diagnostics on a 4-port Token Ring feature card then it was possible for the switch to reset during the rest of the diagnostic tests.
- An SNMP request that asked for multiple fields associated with all of the Addresses in a Port could cause the switch to reset.
- The code that handles this request has been changed to much more efficient.
- There where several changes made to the Route Table (IP) processing. The size of the table was doubled and the age out time was decreased to five minutes. The switch no longer saves routes for frames that our IP stack does not need. A memory leak associated with a table free condition also has been fixed.
- This memory leak could lead to a switch reset.
- A memory leak related to a failure to free acquired memory for scheduling timer tasks has been fixed. The memory leak could lead to a failure to be able to Telnet to the switch, "Available memory insufficient for download" message, or a switch reset.
- A stack overflow condition leading to a switch reset. The problem that was fixed by changing how the storage is acquired.
- The functions now request storage from the heap instead of from the stack.
- If a port reset during Congestion control on a switch the switch could reset.
- Numerous locations in the code were found to have potential memory leaks because the success of the memory allocation request was not checked. The memory leak could lead to a failure to be able to Telnet to the switch, "Available memory insufficient for download" message, or a switch reset.
- The congestion handling for Source-Route Bridging has been improved. A burst of specifically routed frames that the switch with unlearned route descriptors could have lead to a switch reset.
- Transmit Hangs - The have been a few changes made in this area. In previous levels of code it was possible to get false transmit port hang detections that could lead to port resets and other port related issues. The transmit port hang detection code has enhanced to prevent these issues. There also have been fixes added for two other conditions what would result in the same transmit hang port symptom.
- If you defined a SPAN port for a port within a domain that consisted of multiple ports and the monitored port is disabled, the traffic from the other ports would be forwarded to the SPAN port. A change has been made to compensate for the monitoring port not being open.
- The Board Temperature value on the Switch Statistics panel may not have been formatted correctly. If the board becomes overheated, the value will read "OVERHEAT TEMP". However, when the board returns to normal temperature, the value incorrectly read "NORMALAT TEMP". This situation has been corrected and the settings should reflect the current board temperature.
- A confirmation prompt was added to the scroll command on the Master Address Table panel because it may be a lengthy request.
- If you press control characters after you have entered a file name on the Serial Download panel, they could be added to the end of the file name as invisible characters. The Ctrl-c character is one of the control characters. This would result in a "file not found" on the download even though the file name would look correct on the panel. The file name is now checked for these characters to make sure they are not used.
- Ports that are in a fixed configuration in Adapter Mode but not attached will no longer continually reset.
- The help line for the RETURN command has been changed on a number of panels to make it more consistent.
- If a domain that contained a TokenChannel configuration was changed, not all of the ports in the TokenChannel were reset. This situation could result in odd distribution of addresses over all the ports of the TokenChannel. The code has been changed to reset all of the ports in the domain including all of the TokenChannel ports if the domain configuration has changed.
- The alignment of columns of data on the Source Route Configuration, Master Address Table, and Domain Address Table panels has been corrected to accommodate the feature card slot numbers.
- The search command in the Master Address Table and the View Logical Ports panels would only find the first logical port that matched the search instead of all of the entries that matched.
- Alignment problems on the Spanning Tree Statistics panel with feature card ports has been corrected.
- The SNMP object imb8272TsPortSwitchMode incorrectly reported ports in Adaptive Mode to be in Store and Forward Mode.
- On the Source Route Bridge Spanning Tree menu, if you change the path cost for more than one segment, only the last change is saved.
- The code has been corrected to save all of the changes entered.
- The use of ellipsis (...) after selections has been added to a number of panels to make its use consistent.
- Changing the Switch Priority on a given domain caused the Port Path Cost and Port Path Priority to be reset back to the default values.
- The code has been corrected to not reset the Port Path Cost or the Port Path Priority when the Switch Priority is changed.
- The power-up diagnostics incorrectly listed port numbers during the crossport test.
- The Port Statistics panel would incorrectly give the link status if the port went down while the Port Statistics panel was updating and then came back up. The Port Statistics panel would still indicate that the link was down instead of up.
- There was a problem with learning Destination Addresses for secondary TokenChannel ports because the appropriate spanning tree information was not maintained across all ports of the TokenChannel.
- This could cause connection problems across the secondary ports of TokenChannels.
- On the TFTP Download panel, if Enter was pressed with an existing file name in the field the file name would be blanked out. The code has been changed not to blank the file name on the enter key.
- There was problem that resulted in the switch hanging. When this occurred, you would not be able to access the console through the serial port and all processor functions would cease: SNMP, Spanning Tree, Telnet, and Learning. This problem was a result of deadlock condition in the code. Changes have been made to avoid this deadlock condition.
- When the Master Address Table was searched and the specified port was not in the default domain, then the search result would not place the specified entry at the top position.
- A change was made to not count duplicate LAN IDs for STE frames on blocked ports as errors.
- The SNMP linkUp/linkDown Trap was returning the incorrect object id. These traps always returned 1.0 when they should have returned the ifIndex of the port which just came up or down.
- Erroneous "Invalid port entry found" messages could be written to the log. This problem was caused by incorrectly searching the port tables for the address when SRB is active between domains.
- The MAC addresses for Spanning Tree BPDUs were incorrect because they were based off the canonical MAC address of switch instead of the non-canonical address.
- SNMP traps where not being sent out on all domains if more than one domain was configured. This has been corrected so that SNMP Traps will be sent out all domains.
- A condition could occur that caused numerous tasks in the processor to be incorrectly suspended. Another condition was found that caused certain tasks in the processor to be assigned the wrong priority and never run. These problems could result in the processor not responding to requests for Telnet, SNMP, serial console, or Spanning Tree.
- There was a series of invalid warning messages, FS_WRITE and FS_FileSize, that could be displayed during switch IPL or normal operation.
- The SNMP variable dot1dSrPortLocalSegment was not correctly implemented. This variable should now be operational.
- If a bridge in the network updated the message age value of the BPDU with a fractional value, the switch might have discarded it due to an invalid compare to the maximum age value. This problem could have resulted in ports changing states unnecessarily.
- "FS_WriteFile: .... No Space Left On Device" log may get generated in certain environments. Code was added to optimize the utilization of file system.
- "Warning: mb message allocation failure" repeated logged on console. Problem caused by a heap leak when excessive SNMP requests are sent to the switch during heavy loads. The leak has been plugged.
- Switch resets when no receive buffers available. Caused by a "catch-22" situation with no escape path. Only recreatable in hypothetical environments.
- Topology change detected by STP could cause endless address aging loop.
- BPDUs were not being sent out of the ports that were under heavy loads. Modified the FC field in BPDUs for transparent and source routed spanning tree frames to raise their priority. This allows spanning tree to maintained correctly.
- In certain situations, the watchdog timer is not maintained correctly, resulting in the switch to be automatically reset/rebooted. (This problem was only recreatable in developmental versions of code.)
- When upgrading from a previous release, some configuration data could get corrupted.
- In certain situations, ports could begin forwarding frames before the port is in the forwarding state.
- Problem existed in the algorithm of checking for duplicate addresses when a station that was attached in full duplex got moved to another port.
- "...failed to find bootp server on one or more domains" gets logged although the server was already located.
- Excessive number of Lost Frames when switch is in a stress environment. The counter would increment in bursts. Problem was remedied with queuing improvements.
- TFTP downloads to the LAN switch may fail when traffic to the switch gets heavy. This is due to filtering done by the switch to manage congestion. However, in doing the filtering, some of the TFTP packets may get lost, resulting in the download failure. Enhancements were added to the congestion control to give the TFTP packets special consideration.
- The number of learned stations was being incremented incorrectly. The number indicated was larger than the actual count.
- PSM was unable to create filters.
- Sending multiple SETs of IfAdminStatus were not being handled correctly. Only the last was worked.
- sysUpTime in Mib-2 was wrapping every four days. It will now take over 100 years to wrap. (Several other system counters were fixed for the same wrapping condition.)
- Certain scenarios can overrun the switch with SNMP requests, causing a queue overflow and some requests to be dropped. When this occurred, the log "SNMP_Task: QU_Send Failure" appeared on the console screen and recorded in the log. The discarding of SNMP request is not considered a problem, since retries will be attempted. The logging of the event is now done to just the log and not the console.
- Using the PSM, the firmware version was returned in two strings which caused overlays on the PSM screen.
- Fixed a problem where the MORE option on some screens presented blank screens.
- Fixed formatting problems in "View Logical Port Address Tables".
- The screen format of "Transparent Bridge Spanning Tree for Domain" can have the port number and cost run together.
- The screen format of "Spanning Tree Statistics" shifts columns out of line as numbers are incremented.
- Telnet, Bootp, SNMP, TFTP, IP, and Spanning Tree BPDU traffic out of the switch could stop being transmitted under certain circumstances. This change should allow the switch to avoid a specific hang condition encountered when transmitting this type of traffic.
- Two conditions that could cause a Catalyst 2600 port to stop transmitting frames have been fixed.
- The congestion handling has been changed to deal more efficiently with high levels of traffic to the processor. These changes will prevent box resets and other problems associated with congesting the processor.
- When a port was heavily loaded it could cause the spanning- tree BPDUs not be transmitted. This could result in unnecessary spanning-tree transitions on other switches which could cause resets and temporary loops. Changes have been to help guarantee that the spanning-tree BPDUs get transmitted even under heavy load.
- For a 2-Slot card, in the Port Config and Port Status menus, a blank screen was displayed when you selected More.
- The master address was displayed incorrectly.
- A situation that could cause constant Ring purges has been fixed.
- The long pause between the download of the last port and the start of the UART diagnostics has been shortened.
- When trying to send a ping from the IP Configuration panel, a memory failure could occur when pinging invalid IP addresses. This fix clears the table that stores the IP requests.
- SNMP would incorrectly report the Catalyst 2600 Model 216 as a IBM 8272 Model 108.
- Pinging from the IP Configuration panel could cause the console and the IP stack to hang. For this situation to arise you must have IP disabled, an IP address assigned to the domain, a Gateway address assigned and then issue a ping from the IP Configuration panel.
- The sysUpTime variable defined in RFC 1213, Management Information Base for Network Management of TCP/IP-based Internets: MIB-II, wrapped every four days. If the switch had been up for five days the sysUpTime variable would have reported an up time of one day.
- If spanning tree was active and a port reset for any reason the spanning tree information about that port was not correctly cleaned up. This could cause a loop when the port completes its reset.
- Switch-to-switch connections that were not fixed port configurations could come up at 4 Mbps instead of 16 Mbps.
- A condition that created a loop between two or more switches has been fixed. This loop would cause the switches to get congested and could cause them to reset. The connections between the switches either needed to be a TokenChannel or a full duplex link. A specifically routed multicast source routed frame that did not contain the LAN ID from the switch in its RIF was being transmitted between both switches continuously.
- A switch reset condition that was a result of very heavy traffic load with large frame sizes has been fixed. In a multiple switch environment this condition could have caused more than one switch to reset.
- A stack corruption problem has been fixed which could have caused out of memory conditions.
- On the Port Configuration panel, the switching mode has been changed to always report the configuration instead of the current port status.
The following is a list of fixes in release 2.2.4 of the Catalyst 2600:
- The ARI/FCI Bit Option settings of 'Set non-routed only' and 'Never Set' could be reverted to a previous setting when the box was powered off.
- The SNMP Beacon Start Trap being sent did not match the trap specified in the MIB.
- A Token Probe defined on a spanning tree blocked port would cause the port to reset. During this port reset, a loop would be created for about one second. If the code level of the box was less than 2.23 this loop could have caused the box to reset due to congestion this loop caused.
- The sysName, sysContact, and sysLocation variables defined in RFC 1213, Management Information Base for Network Management of TCP/IP-based Internets: MIB-II, would be corrupted if changed to string longer than 15 characters.
- A port could hang and be disabled during insertion. The box would have to be powered off to enable the port.
- When spanning tree was active and a port that was part of a loop was added to the configuration either by resetting an existing port or adding a new connection a loop would be created for about one-half second. If the code level of the box was less than 2.23 this loop could have caused the box to reset due to congestion this loop caused.
- Telnet, Bootp, SNMP, TFTP, IP, and Spanning Tree BPDU traffic out of the switch could stop being transmitted under certain circumstances. This fix addresses a specific problem related to a hang condition caused by a certain size frame generated by the switch to a very busy port.
The following is a list of fixes in release 2.2.1 of the Catalyst 2600:
- The files on the diskette are now prefixed with CIS. In previous releases, the files were prefixed with TRS. If you have a previous release (2.06), you must rename these files with a TRS prefix before loading them.
- When running ports in Adaptive Cut-Through Mode, it was possible for the port to stop transmitting or to reset. This transmission stop or port reset could cause dropped sessions.
- One port failing the hardware diagnostics could cause the remaining ports on the box to incorrectly fail diagnostics.
- Under high traffic conditions when both high and low priority token-ring frames are being sent it is possible for the switch to create an excessive number of Ring Purges. These Ring Purges would significantly impact the traffic on the failing port.
- A timing window existed that could cause the box or individual ports to reset.
- A broadcast storm could cause the box to reset.
- If a port was disabled due to a config loss condition, a reset of the box will now enable that port.
- There were certain situations in which the LAN ID would not be learned.
- IP connectivity to the switch was inconsistent. There were times that you could not ping the switch or use Telnet to access the configuration console.
- The MIB was improperly located and could not be viewed with a generic MIB browser. Due to these corrections, management of the Catalyst 2600 Release 2.2.1 requires an updated version of CiscoView. To obtain the new version:
Step 1 Using a Web browser, access http://www.cisco.com/kobayashi/Library_root.shtml (accessing this URL requires a valid CCO userid and password).
Step 2 Under Network Management, click on CiscoView Upgrade Planner
Step 3 Click on CiscoView 3.1.1 Software Update Packages
Step 4 Click on Cat2600.cv311.P1-1.tar
Step 5 Click on Execute
Step 6 Click on Cat2600.readme
Step 7 Click on Execute
The device package contains two versions of the enterprise MIBs for the Catalyst 2600 device:
- C2600_cisc.my -- This MIB file supports Catalyst 2600 release 2.0.6.
- C2600.my -- This MIB file supports Catalyst 2600 release 2.2.1.
If using a MIB browser tool, the user will see the MIB variables defined in each of the above (under different branches at the same time).
