These release notes describe the features, modifications, and caveats for Software Release 9.17, up to and including maintenance release 9.17(14). For complete Release 9.17 product documentation, refer to the Release 9.1 Router Products Configuration and Reference and the Router Products Configuration and Reference Addendum publications.
Note The
Router Products Configuration and Reference Addendum is integrated into the online version of the Release 9.1
Router Products Configuration and Reference publication.
Software Release 9.17 is software specifically for the Cisco 7000 series of multiprotocol routers. The software is documented in an addendum that is designed to be used with the Release 9.1 Router Products Configuration and Reference publication. To help you use both of these publications to configure the Cisco 7000 series, these release notes highlight some of the differences between Release 9.1 and Release 9.17 features and functionality.
These release notes discuss the following topics:
- Software Release Overview, page 3
- Microcode Software, page 3
- New Features in Release 9.17(14), page 4
- New Features in Release 9.17(13), page 4
- New Features in Release 9.17(12), page 4
- New Features in Release 9.17(11), page 4
- New Features in Release 9.17(10), page 4
- New Features in Release 9.17(9), page 5
- New Features in Release 9.17(8), page 5
- New Features in Release 9.17(7), page 6
- New Features in Release 9.17(5), page 7
- New Features in Release 9.17(4), page 7
- New Features in Release 9.17(3), page 8
- New Features in Release 9.17(1), page 8
- Cisco 7000 Series Interface Processors, page 11
- Important Notes, page 12
Note The following caveat sections include only the most serious caveats; use UniverCD or access CIO to see all the caveats for a release.
- Release 9.17(14) Caveats, page 16
- Releases 9.17(12) and 9.17(13) Caveats/Release 9.17(14) Modifications, page 18
- Release 9.17(11) Caveats/Release 9.17(12) Modifications, page 18
- Release 9.17(9) Caveats/Release 9.17(10) Modifications, page 21
- Release 9.17(8) Caveats/Release 9.17(9) Modifications, page 26
- Release 9.17(7) Caveats/Release 9.17(8) Modifications, page 28
- Release 9.17(6) Caveats/Release 9.17(7) Modifications, page 29
- Release 9.17(5) Caveats/Release 9.17(6) Modifications, page 32
- Release 9.17(4) Caveats/Release 9.17(5) Modifications, page 34
- Release 9.17(3) Caveats/Release 9.17(4) Modifications, page 40
- Release 9.17(2) Caveats/Release 9.17(3) Modifications, page 44
- Release 9.17(1) Caveats/Release 9.17(2) Modifications, page 47
- Microcode Revision History, page 51
- Customer Information Online, page 60
- UniverCD, page 61
The 9.17 releases are close equivalents to the 9.1 releases. Table 1 shows the correspondence between the releases.
Release 9.17 and 9.1 Correspondence
Release ...
| is a Close Equivalent of ...
|
|---|
| 9.17(1)
| 9.1(2)
|
| 9.17(2)
| 9.1(3)
|
| 9.17(3)
| 9.1(4)
|
| 9.17(4)
| 9.1(5)
|
| 9.17(5)
| 9.1(7)
|
| 9.17(6)
| 9.1(8)
|
| 9.17(7)
| 9.1(9)
|
| 9.17(8)
| 9.1(10)
|
| 9.17(9)
| 9.1(11)
|
| 9.17(10)
| 9.1(11.9)
|
| 9.17(11)
| 9.1(12)
|
| 9.17(12)
| 9.1(13)
|
| 9.17(13)
| 9.1(14)
|
| 9.17(14)
| 9.1(15)
|
This correspondence means that most bugs introduced in Release 9.1(15) were also introduced in Release 9.17(14). It also means that most bugs resolved in Release 9.1(15) were also resolved in 9.17(14), most bugs resolved in 9.1(14) were resolved in 9.17(13), and so on.
Table 2 lists the current microcode versions. Note that for the Cisco 7000 series, microcode software images are bundled with the system software image. Bundling eliminates the need to store separate microcode images. When the router starts up, the system software will unpack the microcode software bundle and load the proper software on all the interfaces.
Note We strongly recommend that you use the microcode bundled with the system software as a package. Overriding the bundle could possibly result in incompatibility between the various IPs in the system.
Current Cisco 7000 Microcode Versions
Processor or Module
| Current Microcode Version
|
|---|
| SP (Switch Processor)
| 10.7
|
| EIP (Ethernet Interface Processor)
| 10.0
|
| FIP (FDDI Interface Processor)
| 10.2
|
| FSIP (Fast Serial Interface Processor)
| 10.6
|
| HIP (HSSI Interface Processor)
| 10.1
|
| TRIP (Token Ring Interface Processor)
| 10.1
|
There are no new features in Release 9.17(14).
There are no new features in Release 9.17(13).
There are no new features in Release 9.17(12).
There are no new features in Release 9.17(11).
This section describes new features in Release 9.17(10).
The Cisco 7000 series has an improved buffer algorithm in the microcode. The new algorithm requires that all microcode be changed. All microcode being run in a chassis must use either the old buffering scheme or the new one. That is, all versions running must be either 10.x or all versions running must be 1.x. (This doesn't apply to the microcode in the ROMS on the boards.) The exception is SIP version 1.2, which works with only the older buffering scheme. Other than SIP, if there is any interface processor whose version number is not in the same group (10 or 1) as the SP, the interfaces on that interface processor will not function.
The FSIP E1 G.703/G.704 is a dual port adapter that provides direct connectivity to leased line services. The E1 port adapter combined with the FSIP directly connects the Cisco 7000 series routers to framed and unframed 2.048 Mbps leased line services. The E1 port adapter also supports loopback tests, fractionalized bandwidth (a multiple of 64 Kbps), internal or external clock signal, and CRC-4 for data integrity.
This section describes the new feature in Release 9.17(9).
Release 9.17(9) supports new microcode versions HIP 1.2 and TRIP 1.2.
This section describes new features in Release 9.17(8).
A new router in the Cisco 7000 series is the Cisco 7010, which has a 5-slot chassis.
Release 9.17(8) supports a 64 MB route processor.
Two new microcode versions are bundled with Release 9.17(8): EIP 1.1 and FIP 1.4
With Release 9.17(7), the microcode for Cisco 7000 series interface processors is now bundled with the 9.17 system software image. Previously, microcode images were released and distributed separately, usually on a floppy disk. The latest released and generally available microcode version for each IP is now compressed and included with the 9.17 system image. When release 9.17(7) or later is installed, the new microcode images are automatically decompressed and placed into the appropriate IPs whenever you reboot the system, remove or install an IP, or reload the system or microcode. However, you can still override this default with boot instructions in the configuration file.
With Release 9.17(7), the microcode software is now bundled with the system software image. Previously, the microcode was shipped on a separate floppy disk. Bundling eliminates the need to store separate microcode images. When the router starts up, the system software will unpack the microcode software bundle and load the proper software on all the interfaces.
The following summarizes the related commands:
To use the interface code in the bundle, no action is required; this is the default. If for some reason there is no usable microcode in the bundle for a particular IP, the code in ROMS on the IP is used.
To use the code in ROMS, enter the configuration command:
microcode interface-type rom
To use a specific flash file for a board, enter the configuration command:
microcode interface-type flash filename
Use the preceding command in those cases when a code patch is separately shipped as an interim measure until the new interface code is completely qualified and released. If there is a problem with the flash file, such as a corrupt or wrong file, the default (system bundle) is loaded instead.
To force a microcode reload, enter the interface configuration command:
microcode reload
To show the microcode bundled into the system, enter the EXEC command:
show microcode
A sample display of the show microcode command follows:
Router# show microcode
Microcode bundled in system
Card Microcode Target Hardware Description
Type Version Version
---- ------- --------------- -----------
SP 161.18 11.x SP version 161.18
EIP 1.0 1.x EIP version 1.0
TRIP 1.1 1.x TRIP version 1.1
FIP 1.3 2.x FIP version 1.3
HIP 1.0 1.x HIP version 1.0
SIP 1.1 1.x SIP version 1.1
FSIP 161.72 1.x FSIP version 161.72
The show controller cbus command is modified; the line after each interface shows where the microcode was loaded from.
Release 9.17(5) provides support for the Fast Serial Interface Processor (FSIP). The FSIP provides four or eight serial network interfaces for the Cisco 7000 series router.
The command for specifying the location of the microcode image has been changed to add an argument for the FSIP. This command has the following syntax:
microcode interface-type [rom|flash filename]
no microcode interface-type [rom|flash]
For the argument interface-type, you can now specify fsip in addition to eip, fip, hip, sip, sp, and trip.
For the FSIP, the internally generated clock on the serial interface is generated automatically. Therefore, you do not need to specify a transmit-clock-internal command.
Release 9.17(5) introduces SNMP environmental monitor MIB support. The Cisco 7000 supports the platform-independent features of the MIB. The envPresent variable will return a value of 4 to indicate that support for the Cisco 7000 series is present.
Release 9.17(4) supports additional information about the Serial Interface Processor (SIP). The output of the show interfaces serial command has changed to support this additional information. When a SIP is installed, the following additional line is displayed in the "output rate" section of the display:
1 carrier transitions, rts up, cts up, ctr, up, dsr up
Release 9.17(3) supports the High-Speed Serial Interface (HSSI) Interface Processor (HIP), which provides a single HSSI network interface for the Cisco 7000 series. The network interface resides on a modular interface processor that provides a direct connection between the high-speed Cisco Extended Bus (CxBus) and an external network.
The method for specifying a HIP interface differs from that documented in the Release 9.1 Router Products Configuration and Reference publication. To define a HIP interface, use the following command:
interface hssi slot/port
To reset a HIP interface, use the following command:
clear interface hssi slot/port
To display the status of a HIP interface, use the following command:
show interfaces [hssi slot/port] [accounting]
The encapsulation methods and debugging commands are the same as for other serial interfaces.
This section describes the hardware and software features of Software Release 9.17(1), which is designed to be used with the Cisco 7000 router. See the Cisco 7000 Hardware Installation and Maintenance publication for a complete description of the Cisco 7000 hardware.
Release 9.17(1) supports the following hardware and software features:
- Network interfaces--Reside on modular interface processors in combinations of serial, Ethernet, Token Ring, and FDDI.
- Interface processors (IPs)--Provide a direct connection between the high-speed Cisco Extended Bus (CxBus) and the external network.
- Online installation and removal (OIR)--Allows you to add, replace, or remove CxBus without interrupting the system power or entering any console commands. (OIR is not supported for the Serial Interface Processor [SIP].)
- Redundant power supply option--Maintains input power without interruption if one supply fails.This applies to the Cisco 7000 only.
- Environmental reporting function--Helps to maintain normal system operation by troubleshooting adverse environmental conditions. If adverse environmental conditions reach a critical level, the system shuts down to avoid equipment damage.
- Flash memory--Minimizes network maintenance and support time by allowing multiple software images to be loaded remotely for easy software upgrades.
- Downloadable microcode--Allows you to load microcode from Flash memory without having physical access to the router, and to load new microcode without rebooting the system.
Release 9.17(1) allows you to download updated microcode images into Flash memory instead of replacing the EPROMs on the boards. You can download new microcode versions, store multiple versions in Flash memory, and boot from them just as you can with the system software images. System software upgrades also can contain upgraded microcode images, which load automatically when the new software image is loaded.
The SP and all interface processors have a writable control store (WCS) that stores microcode from either the onboard ROM or from Flash memory. The default operation is to load the microcode from the ROM on each board. Use the following command to load the microcode from a Flash memory file or to manually load it from ROM:
[no] microcode interface-type [flash|rom] [filename]
To reload a different microcode version during operation, use the following command. Note that system operation will cease after you issue this command while the system reinitializes the interfaces.
microcode reload
This section describes features of and enhancements to the Cisco 7000 environmental monitor software.
Display temperature and voltage information on the Cisco 7000 console using the following command:
show environment [all|last|table]
The keyword table displays current environmental status along with a table of voltage and temperature parameters for the system.
Set the current date and time using the following commands in privileged EXEC mode. This information is used in a variety of show displays, including environmental monitoring and version displays.
date
time
Display the current date and time using the following EXEC commands:
show {date|time}
This section describes features and enhancements for the Cisco 7000 interface configuration software.
The Cisco 7000 supports online insertion and removal (OIR), which allows you to remove and replace CxBus interface processors without shutting down system power. You can shut down individual interfaces before removing interface processors and then restart the interfaces after inserting interface processors with only minimal disruption of service and without causing other software or interfaces to shut down.
This section documents changes to the interface configuration and interface monitoring command syntax.
All examples in the Release 9.1 Router Products Configuration and Reference publication that include interface configuration commands should be modified to reflect the Release 9.17 command syntax as follows:
- Release 9.1 interface command syntax as documented in the Release 9.1 Router Products Configuration and Reference publication is as follows:
interface type unit
- For example, a Release 9.1 interface command might read as follows:
interface serial 0
- Release 9.17 interface command syntax as documented in Router Products Configuration and Reference Addendum is as follows:
interface type slot/port
- For example, a Release 9.17 interface command might read as follows:
interface serial 2/0
Enable NRZI encoding on a serial interface using the following command:
[no] nrzi-encoding
For SIP cards, enable the internally generated clock on a serial interface using the following command:
[no] transmit-clock-internal
Note that the internal clock is automatically enabled for FSIP DCE interfaces.
Invert the clock signal on an interface using the following command:
[no] invert-transmit-clock
Microcode, OIR, and environmental monitor error messages are provided.
Cisco 7000 series interface processors have different names from the interface cards documented in the Release 9.1 Router Products Configuration and Reference publication. Table 3 provides general interface card/interface processor conversion information. This table will help you to use the Router Products Configuration and Reference Addendum with the Release 9.1 Router Products Configuration and Reference publication. For example, the (route processor) RP card on the Cisco 7000 provides the same basic functionality as the MC+ and ENVM cards on other Cisco routers.
Interface Processor Conversion Table
| Release 9.1 (AGS+) Card
| Release 9.17 (Cisco 7000)
Processor Card
| Release 9.17 (Cisco 7000) Processor Options
|
|---|
| CSC/4
| RP (Route Processor)
| --
|
| ENVM
| RP (Route Processor)
| --
|
| MC+
| RP (Route Processor)
| --
|
| CCTL2
| SP (Switch Processor)
| --
|
| C2MEC
| EIP (Ethernet Interface Processor)
CX-EIP2, CX-EIP4, CX-EIP6
|
2 and 4 ports
6 ports
|
| C2CTR
| TRIP (Token Ring Interface Processor)
CX-TRIP4
|
2 or 4 ports
|
| C2FCI(T)
| FIP (FDDI Interface Processor)
CX-FIP-MM
CX-FIP-SS
CX-FIP-MS
CX-FIP-SM
|
Multimode to multimode
Single mode to single mode
Multimode to single mode
Single mode to multimode
|
| SCI
| SX-SIP4 or pre-FSIP
| 4 ports available for EIA/TIA-232, EIA/TIA-449, V.35, and X.21 connectivity
|
| --
| FSIP (Fast Serial Interface Processor)
| 4 or 8 ports available for EIA/TIA-232, EIA/TIA-449, EIA/TIA-530, V.35, and X.21 connectivity
|
| HSCI
| HIP (High-Speed Serial Interface Processor)
| --
|
This section describes cautions about using the Release 9.17 software. The information in this section supplements that given in the section "Releases 9.17(12) and 9.17(13) Caveats/Release 9.17(14) Modifications" later in these release notes.
Cisco 7000 series microcode is bundled with system software. You cannot pull the individual microcode images out of the bundle and use them with other versions. For example, if SP 1.6 is released with 9.17(8), you cannot pull SP 1.5 out of the 9.17(7) bundle and use it with 9.17(8).
In order to use Release 9.17, you must be using SP Microcode Version 1.4.This microcode must reside in ROM; it cannot be loaded from Flash memory. During the boot process, the system accesses the SP microcode. If the SP microcode ROM contains a version earlier than 1.4 and the router contains an FSIP, the system may fail to boot properly.
In order to boot into the ROM monitor, a configuration register jumper change is required. Refer to the Cisco 7000 Hardware Installation and Maintenance publication.
With software releases prior to Maintenance Release 9.17(11), there is a 3- to 5-second disruption of normal operation when you remove an interface processor and an 11- to 15-second disruption when you insert one. With Maintenance Release 9.17(11) and later, there is no significant or measurable disruption to normal operation during interface processor removal or insertion.
Boot commands issued from the ROM monitor take precedence over those in configuration memory. For example, if you are booting from the ROM monitor, a boot system command in your configuration file will be ignored. The boot network and boot host configuration commands are valid when booting from the ROM monitor. Use the service config configuration command to implement the boot host and boot network commands.
Example
In the following example, the file will be netbooted rather than loaded from Flash memory, as indicated by the configuration file. Boot commands issued from the ROM monitor take precedence over commands in configuration memory. This example will, however, load the host configuration file example-confg and the default network configuration file, network-confg, from 131.108.111.111.
router# show config
Current configuration:
version 9.1
!
hostname router
!
enable-password xxxxxxx
service config
!
boot host example-confg 131.108.111.111
boot system flash gs7-k.917-0.4
boot system gs7-k.917-0.4 131.108.111.111
boot system rom
!
router# wr term
router# reload
[confirm]
%SYS-5-RELOAD: Reload requested
System Bootstrap, Version 4.6(0.16), BETA SOFTWARE
Copyright (c) 1986-1992 by cisco Systems
RP1 processor with 16384 Kbytes of memory
> b gs7-k.917-0.4 131.108.111.111
You must write your microcode configuration command to memory using the write memory command in order to preserve it. If you do not write the configuration to NVRAM and you reboot your system, the router will revert to using the image that is in ROM or will implement the configuration commands that have been written to memory.
Many UNIX compression programs produce files with the suffix ".Z". In certain instances (notably, when booting with the b command from the ROM monitor), the system does not understand uppercase names. To ensure the ability to boot the software in all cases, rename the output files from the UNIX "compress" facility to a name that does not contain any uppercase characters.
When booting the system software from a TFTP server, do not copy the 9.17 system software image to the TFTP server, then copy it a second time. If you do, the second image will be appended to the first image rather than writing over it, and the image will not function in your routers. If you want to copy the image a second time, first delete the image from the destination directory on the server, then recopy the image.
Also, do not make any typographical errors while typing the name of the system software image you are copying. If you type the name of a file that does not actually exist, and then tell the router to erase the existing image in Flash memory, you erase the only working system software image in Flash memory. You still have a working image in RAM, so your router should still function normally. To recover from the accidental Flash memory erasure, execute the copy tftp flash command again to load the appropriate image into Flash memory.
When you attach a cable to or detach a cable from an FSIP port, you must disable and then reenable the port in order for the show interface commands to correctly display the actual state of the electrical connection.
When setting the bandwidth, the bandwidth that is displayed with the show interfaces command may not match for some higher bandwidths because some roundoff is performed on the number you entered. The values shown match those seen in IGRP update packets and hence are more useful for debugging.
As of Software Release 9.1, the router automatically translates old default network commands into appropriate static routes. The translation is completely transparent.
The Token Ring Interface Processor (TRIP) uses an MTU size of 4464 bytes when running at 4 MB and an MTU size of 8136 bytes when running at 16 MB. Token Ring interfaces between a TRIP and a different Token Ring card must use the lower MTU size of 4464 bytes. This is especially important when using CLNS, because two neighboring routers can send hello packets to form IS-IS adjacencies only if the MTU size is the same at both ends of the interface.
To set the MTU size, use the mtu interface subcommand.
To make changes to parameters on X.25 interfaces, you must first shut down the interface.
Access control lists assigned to an AppleTalk interface using the appletalk access-group interface subcommand deny access to packets that originate at the source router. This behavior is contrary to ACL behavior for other protocols, such as TCP/IP, in which access is denied only to packets that the local router is forwarding.
In the chapter "SDLLC: SDLC to LLC2 Media Translation," in the Router Products Configuration and Reference publication, the section entitled "The Cisco SDLLC Function" mistakenly represents that Cisco's SDLLC can support IBM 5494 devices. SDLLC supports only SDLC-attached PU type 2 devices; it does not support PU type 1, PU type 2.1, PU type 4, or PU type 5 devices. However, on the Token Ring side of the SDLLC interface, it is possible to connect a PU type 4 (front-end processor) or type 5 device (host), or an AS/400 computer, which operates in PU2.1 and host emulation modes.
Note that these restrictions do not exist with STUN (SDLC to SDLC). STUN supports any PU type running over SDLC.
When applying a SAP update delay to a Novell interface, Novell indicates that the delay should not exceed 120 ms and recommends that it be much smaller than 120 ms. Delay values in the range of 2 to 8 ms are common. If you need to use a larger SAP update delay time, you should increase the size of the input hold queue using the hold-queue length in interface subcommand.
The environmental monitor in Software Release 9.17(7) can incorrectly report a high internal temperature and display an airflow warning message when the internal air temperature is actually still within the Normal operating range. If you observe the following message:
%ENVM-2-TEMP: Airflow temperature has reached WARNING level at 60(C)
issue the show environment table command and verify that the Inlet air temperature is within the Normal range (see the following example). If so, even if the Airflow temperature is shown within the Warning range, ignore the message. This is an anomaly in the temperature calculations, and will not affect operation.
Following is an example of the show environment table display with the erroneous Airflow temperature:
Temperature Parameters:
SENSE WARNING NORMAL WARNING CRITICAL SHUTDOWN
-------|-------------|------------|-------------|--------------|--
Inlet 10 24(C) 39 46 64
Airflow 10 60 65(C) 70 88
Table 4 provides the temperature thresholds:
Processor Monitored Temperature Thresholds
| Parameter
| Warning
| Normal
| Warning
| Critical
| Shutdown
|
|---|
| Inlet air
| <10°C
| 10 to 39°C
| 39 to 46°C
| 46 to 64°C
| >64°C
|
| Airflow
| <10°C
| 10 to 70°C
| 70 to 77°C
| 77 to 88°C
| >88°C
|
This section describes possibly unexpected behavior by Release 9.17(14). Unless otherwise noted, these caveats apply to all 9.17 releases up to and including 9.17(14). Note that, in general, most of these bugs also exist in Release 9.1(15). This section includes only the most serious caveats; use UniverCD or access CIO to see all the caveats for this release.
- When some routers on the path taken by the Path Tool have routing table misconfigured, the Path Tool detects a cyclic path and displays an error message to remind you to check the routing configuration on these routers. [CSCdi21237]
- A router receiving a MOP connection request through its serial port for one of its LAN port addresses responds with the LAN port's burnt-in address instead of the actual hardware address. If the requesting host uses the DECnet-style MAC address of the router in the request packet, the host will not recognize the response packet sent by the router, because it sees a different address in the "source" field. This causes the requesting host to time out on the connect request. [CSCdi26991]
- When IPX routing is enabled on a Token Ring interface and there is a source-route bridge network behind the ring, a multiring ipx all command is used to cache the RIF in the router. During normal operation all is well. But when a station is moved from one ring to another ring (for example, from 0B8 to 0B1), the station cannot reach the server. Looking at the RIF cache on the AGS+, it is fine. However, by analyzing the frames with a Sniffer, we can see the "create connection request" from the station with a good RIF field, but the answer from the AGS+ shows the previous RIF (the RIF before the station was moved). The workaround is to disable the IPX route cache or to clear the IPX cache when a station is moved. This is a general problem with all routed protocols. The RIF code does not inform the routing protocols when an entry in the table changes. Therefore, the cache entries become invalid. [CSCdi17099]
- RIP updates are lost during redistribution with OSPF plus the default route. This problem occurs in an environment where OSPF is redistributed into RIP and RIP is redistributed into OSPF. Under certain circumstances, the RIP updates are no longer interpreted by the router, but are forwarded to the gateway of last resort. [CSCdi18372]
This section describes possibly unexpected behavior by Releases 9.17(12) and 9.17(13).Unless otherwise noted, these caveats apply to all 9.17 releases up to and including 9.17(13). For additional caveats applicable to Releases 9.17(12) and 9.17(13), see the caveats sections for newer 9.17 releases. The caveats for newer releases precede this section. This section includes only the most serious caveats; use UniverCD or access CIO to see all the caveats for this release.
All the caveats listed in this section are resolved in release 9.17(14). Note that, in general, most of these bugs were also resolved in Release 9.1(15).
- Setting the llc2 ack-max parameter to the value n actually causes the router to acknowledge every n + 1 packets. Because this value cannot be set to zero, this makes it impossible to tell the router to acknowledge every packet. [CSCdi27034]
- If an R16M Token Ring card is administratively down and the router is reloaded or powered off and back on, the card will try to initialize its interface and will no longer be administratively down. This appears to happen only on the R16M card. [CSCdi17976]
- When multiple FDDI cards are present in the router, the interfaces in the lower slot positions may lose their downstream neighbors. [CSCdi25764]
This section describes possibly unexpected behavior by Release 9.17(11). Unless otherwise noted, these caveats apply to all 9.17 releases up to and including 9.17(11). For additional caveats applicable to Release 9.17(11), see the caveats sections for newer 9.17 releases. The caveats for newer releases precede this section. This section includes only the most serious caveats; use UniverCD or access CIO to see all the caveats for this release.
All the caveats listed in this section are resolved in release 9.17(12). Note that, in general, most of these bugs were also resolved in Release 9.1(13).
- The netbios enable-name-cache command is not working in a topology that has two or more paths to access to the workstations. The show rif command shows both paths, but the show netbios-cache command shows only one path. [CSCdi18524]
- On half-duplex SDLC serial interfaces, the show interface serial n command returns incorrect information regarding the RTS and CTS signal timing information. This has no operational impact on the SDLC link. [CSCdi23781]
- Fast switching large IPX packets from a high-MTU interface (such as Token Ring or FDDI) to an MCI serial card may corrupt MCI memory, resulting in an %MCI-3-SETUPERR message. This is an issue only if you use a version of IPX that uses packets larger than the default 576 (using LIPX or BIGPAK). [CSCdi22888]
This section describes possibly unexpected behavior by Release 9.17(10). Unless otherwise noted, these caveats apply to all 9.17 releases up to and including 9.17(10). For additional caveats applicable to Release 9.17(10), see the caveats sections for newer 9.17 releases. The caveats for newer releases precede this section. This section includes only the most serious caveats; use UniverCD or CIO to see all the caveats for this release.
All the caveats listed in this section are resolved in release 9.17(11). Note that, in general, most of these bugs were also resolved in Release 9.1(12).
- Executing the show appletalk interface command may cause the system to restart itself. This happened on interfaces configured with many zones. [CSCdi18875]
- When system uptime exceeds approximately 24.45 days, AppleTalk interfaces can unexpectedly hang during restarts and never become operational. The only workaround is to reload the system. [CSCdi20052]
- Under rare circumstances, the clear line command fails to clear the process running on that line. A show process command shows that the process on that line has an inappropriate and rapidly increasing number in the "invoked" column. [CSCdi16063]
- If a SAP update packet is received with an invalid length, much larger than the data actually contained in the packet, the system may reload. It is also possible, but unlikely, that invalid server entries may appear in the show ipx server table. When these packets are received, they should be counted as SAP format errors and the counter displayed by the show ipx traffic command should increment. [CSCdi19010]
- A router that has been configured as a Level 1 router should not send out Level 2 routing updates. [CSCdi20884]
- On Cisco remote access routers, the configuration interface subcommand bridge-group group output-pattern grouplist does not function properly. All packets will be passed through this interface regardless of the filters set in this command. [CSCdi13619]
- In systems configured to support the spanning-tree bridging protocol, the root bridge BPDUs reappear at the root bridge in a HSSI environment. [CSCdi18812]
- Translational bridging of Novell IPX packets from Ethernet to FDDI and back to Ethernet fails if the source MAC address ends with 0xff All other protocols bridge correctly with this MAC address, and all other MAC addresses bridge correctly with all protocols. [CSCdi21873]
- In OSPF, when a neighbor goes down, a host route for that neighbor is incorrectly added. A possible workaround is to trigger the rebuild of OSPF router link state advertisement by changing interface metric or by rebooting. [CSCdi21103]
- The system may crash and reload itself while it is configured for DECnet convergence or router ISIS Level 1/Level 2. A combination of the following conditions causes this to happen: (a) There is a variably subnetted route; (b) Multiple routes hash into the same subnet table hash bucket; (c) There is a subnet with netnumber == major_net and mask == major_net_mask; and (d) Another subnet follows. The root cause is the same as CSCdi20345. [CSCdi18659]
- The original default of the ipx gns-response-delay command was 500 ms. This value fixes an issue in NetWare 2.x with dual-connected servers in parallel with a router NetWare 2.x was the most common release. NetWare 3.x and later do not have the same issue, and a nonzero GNS response delay may cause problems in certain situations. The default of the ipx gns-response-delay command has been changed to 0. [CSCdi22285]
- When X.25-over-TCP (XOT) sends a Call Confirm that modifies one of the two proposed flow control facilities (window sizes or maximum packet sizes), the values may be set to 0, which is illegal. [CSCdi21602]
This section describes possibly unexpected behavior by Release 9.17(9). Unless otherwise noted, these caveats apply to all 9.17 releases up to and including 9.17(9). For additional caveats applicable to Release 9.17(9), see the caveats sections for newer 9.17 releases. The caveats for newer releases precede this section. This section includes only the most serious caveats; use UniverCD or access CIO to see all the caveats for this release.
All the caveats listed in this section are resolved in release 9.17(10). Note that, in general, most of these bugs were also resolved in Release 9.1(11).
- The show apple interface command may cause the system to restart itself. This would happen in interfaces configured with many zones. [CSCdi18875]
- Under rare circumstances, the clear line command will fail to clear the process running on that line. A show process command will show that the process on that line has an inappropriate and rapidly increasing number in the "invoked" column. [CSCdi16063]
- If a SAP update packet is received with an invalid length, much larger than the data actually contained in the packet, the system may reload. It is also possible, but unlikely, that invalid server entries may appear in the show novell servers table. When these packets are received, they should be counted as SAP format errors and the counter on show novell traffic should increment. [CSCdi19010]
- While converting from DECnet Phase IV to Phase V (and vice versa), the router holds back a converted packet once in a while, and sends it out when some other event (for example, routing update or keepalives) happens. This sporadic delay in packet transmission results in degradation of end-to-end DECnet performance. [CSCdi20151]
- The problem reported here occurs because of incorrect "interface mtu negotiation," and will be seen on any interface whose default MTU is larger than the Ethernet MTU (for example, FDDI). When the VAX comes up, we end up negotiating a block size that is larger than the maximum value that we are willing to process (1524). Consequently, all adjacent routers end up sending larger sized updates, which we reject. This makes all destinations behind the router unreachable. [CSCdi20225]
- FEP-to-FEP local acknowledgment sessions blocked due to after SDLC-TG packet SQN=1 was delivered before packet SQN=0. The code has been optimized to prevent this from happening (automatic resequencing). [CSCdi17904]
- If an RSRB remote-peer is defined but not currently in use, the router may reload due to a software forced crash. The workaround is to remove any peers not currently in use from the configuration. [CSCdi17934]
- After running for an extended period of time with remote source-route bridging configured, the console may display "%SYS-2-LINKED: Bad enqueue of nnnnnn in queue nnnnn" messages. These will be followed by a traceback message containing several hex numbers. RSRB will continue to function normally. The error message is printed under the wrong condition and can be ignored. Future versions of software will only print this message when appropriate. [CSCdi18003]
- In low-end routers such as Cisco 4000 and Cisco 3000, the Token Ring interface ignores IP packets that have single-route or all-route broadcast rif. The correct behavior is to accept the packet and subsequently route it when ip routing is turned on. [CSCdi18131]
- When source-bridge translational bridging is used in a dual TIC (token-ring interface) environment, the RIF is cached for the first return explorer from the destination. Subsequently, if another return explorer from the same destination is seen with a shorter RIF, the RIF cache on the router is updated. This causes the end stations to reinitiate their sessions. The correct behavior for source-bridge translational bridging in a dual TIC environment is to cache the shortest rif based on the fastest return and locks it. A timer is then started. If there is no packet from the destination and timer expires, the RIF cache for the destination is removed. Subsequently, new returns from alternate routes may be cached. If there are packets from the destination station, then the RIF from the cache is applied and the timer is reset. [CSCdi18169]
- In a local acknowledgment environment, incoming disconnect packets where not handled properly and remained on the input queue. The Token Ring input queue would fill up completely and cause continuous Token Ring resetting. [CSCdi18222]
- For SDLLC, there are certain situations in which LLC2 congestion across the RSRB connection can cause the LLC transmit queue to be overrun. If this is the case, a packet that has been acknowledged on the SDLC interface can get dropped on the LLC queue and cause a session interruption. One of the symptoms of this occurring is the SNA LU-LU session ending with an UNBIND due to a skipped sequence number in the TH header. Changes have been made in the SDLLC code to allow the system to sense congestion on the LLC2 side and apply back pressure on the SDLC side by sending RNRs. The current/maximum values of the LLC transmit queue can now be displayed with the show llc2 command. The default value is 200, with a maximum of 2000 allowed. The value can be changed with the llc2 txq number interface configuration subcommand. [CSCdi18898]
- SDLLC configurations with System 88 machines may fail due to a known limitation in their ability to handle the direction bit in the RIF field. The fix modifies the router behavior to allow for this contingency. [CSCdi18921]
- When applying NetBIOS access lists with rsrb remote-peer, access list statements on a system with active SRB traffic, the router may reload due to a bus error. The fix changes the system code so that it handles these conditions in a more graceful manner. [CSCdi18993]
- A Reverse Ethernet SDLLC configuration with local acknowledgment enabled may cause a reload due to a software forced crash (Jump to zero). The code fix fixes a defect in the local acknowledgment code that resulted in a procedure being called recursively. The circumvention is to turn local acknowledgment off for Reverse Ethernet SDLLC. [CSCdi19067]
- Use of rsrb remote-peer 100 tcp n.n.n.n lsap-output-list number causes a slow memory leak under heavy RSRB load. The show process memory command will show an increasing amount of memory taken by the SRB background process. The workaround is to remove the access list and achieve the same desired behavior through the use of access-lists applied on the Token Ring interfaces. [CSCdi19106]
- A configuration in which SDLLC and Reverse SDLLC are configured back to back does not work properly. A sample of this configuration would be a SDLC attached FEP going to a TR through the router (Reverse SDLLC) to another router to an SDLC attached PU. This configuration is common where a TIC for a FEP is not available and the customer requires both remote SDLC and Token Ring connectivity through the router network to a single SDLC line on the host side. The fix will ensure this configuration works. The workaround is to configure STUN for SDLC attached PUs and Reverse SDLLC for Token Ring attached PUs going to separate SDLC FEP lines on the host side. [CSCdi19148]
- Access lists of the form rsrb remote-peer nnn tcp ip address netbios-output-list host access-list-name do not function properly. The workaround is to use the same access list applied on the Token Ring interface to achieve the desired result. [CSCdi19198]
- The stun cos-enable command causes unnecessary FID4 frame resequencing. The network gains no benefit and the routers are performing unnecessary work, so the feature is being removed. In addition the feature was causing packets to be delivered out of TG-sequence, which in rare occasions causes blocking TGs. [CSCdi19357]
- When the T1 timer is coded too short on a multidrop SDLC line, SDLC messages of the form "data from wrong address! got address" (where are SDLC poll addresses in hex) appear on the console. In a large multidrop configuration, the amount of these messages is excessive. The code changes this behavior so that the messages appear only when debug sdlc is turned on. Note that these messages are informational only and that polling of the down-stream SDLC devices does continue. [CSCdi19376]
- A FEP operating as a secondary SDLC station is allowed to load a remote FEP operating as a primary SDLC station. The opposite has been possible since 9.1(9). Before a FEP is loaded with an NCP Gen, it does not have an SDLC role. The SDLC role is negotiated via XID exchange when the remote FEP is activated. [CSCdi20463]
- Systems configured to support the spanning-tree bridging protocol will experience the root bridge BPDUs reappearing at the root bridge in a HSSI environment. [CSCdi18812]
- When transparently bridging from Token Ring to serial on a Cisco 4000, a 2-byte length field is inserted without correcting the frame size. During the copy, the last two bytes of the packet get lost. This only happens when flooding packets. [CSCdi18814]
- On the Cisco 3000 series routers, when using dial-on-demand routing, a transition of CTS or DSR can appear as a transition of DCD when spoofing. [CSCdi19053]
- The router continually reports "%SYS-2-NOBLOCK: event dismiss with blocking disabled" errors preventing the router from processing other information. Reloading the router temporarily resolves the issue. [CSCdi18565]
- Default-network does not work properly depending on subnet used. [CSCdi18743]
- If an FDDI interface on a router is reset via the no shut command, IP routes would be deleted from that interface. But since the FDDI ring is still in operational mode, there is no event generated to let OSPF know that routes have gone and recalculated SPF. [CSCdi19255]
- The source address-sensitive form of the distance command now works for OSPF. It formerly was silently ignored. Note that, for OSPF, this command has slightly different semantics, since the source address is matched based on the router ID of the router that originated the route within the OSPF area, rather than the next-hop router. [CSCdi19369]
- The router and communication servers allow remote users to Telnet into VTY ports by connecting to ports 20xx/40xx/60xx/80xx. All of the standard VTY/TTY security features, such as passwords, TACACS, and the ability to block access with the access-class in command have always been supported, even when connecting to a high port. However, since many customers are unaware of this functionality, they do not take it into account when constructing packet filtering firewalls. Since this functionality can be explicitly enabled and configured by use of the VTY rotary feature, the default behavior is not necessary. This is not a security bug or hole, but rather a behavior that should be avoided as a matter of prevention due to its obscurity. [CSCdi20050]
- OSPF can choose and install nonoptimal interarea and external routes when there are multiple link state advertisements for the same destination advertised by multiple Area Border Routers (or Autonomous System Boundary Routers for external route). This can cause a routing loop if other neighboring routers still install the shortest path to the destination. This problem will only happen after the system has been up for a period of time. The length of this period depends on how much connectivity changes have occurred. In a fairly busy network, the estimate length of this period is around five to six weeks. [CSCdi20071]
- After an OSPF router installed a default route to network 0.0.0.0 that is advertised in an external link state advertisement (LSA) by an Autonomous System Boundary Router (ASBR) and there is any connectivity change happens in the network that triggers SPF calculation, the router will not reinstall the default route. This problem is introduced in the following software version: 9.1(11.4), 9.17(9.2) and 9.21(3.1). There is no workaround for this problem. [CSCdi20401]
- Every time an OSPF router notices its neighbor state change on an interface (either by seeing new Hello packets or the lack of Hello packets for a RouterDeadInterval) and attempts to reoriginate its own router link state advertisement (LSA) but there is no change that needs to be reflected in the router LSA, a piece of memory of the size of the router LSA would be permanently consumed. This problem manifests itself by a slowly declining amount of free memory shown in show memory command. There is no workaround to this problem. This problem is introduced in software version 9.1(11.5). [CSCdi20849]
- The IS do not put dynamically learned ES over point-to-point in the L1 LSP. So the other ISs do not have a route to that ES. This fix take care of the problem. [CSCdi18856]
- There is a problem with type 4 NetBIOS broadcast traffic looping in redundant topologies. The workaround is to eliminate redundancy. [CSCdi18824]
- The router may restart when an output-sap-delay is configured, an update is in progress, service entries are timing out (older than 4 times the sap update interval), and a Get-Nearest-Server request is received. [CSCdi20370]
- The system implements diagnostic TCP servers on ports 7 (ECHO) and 9 (DISCARD). Release 10.0 adds a server on port 19 (CHARGEN). These services cannot be disabled, which is worrisome to users implementing firewalls. Also, the system mistakenly listens for XRemote connections on port 10000, corresponding to the nonexistent rotary group 0. [CSCdi20077]
- In 9.1 releases beginning with 9.1(6.4), the router does not correctly honor the propagate command. Broadcast packets will be dropped when they should be forwarded. This is most noticeable when performing a newrev command on a serverless client when there is a serial line separating the client and the server. [CSCdi20428]
- This problem is noticed in X.25 environments. A message of "System restarted by error - Jump to zero" will appear. If you do a show stack, you will see a two-line stack trace. The cause is related to failed PAD Calls; an area of memory is modified after it has been returned as no longer in use. Under circumstances of heavy load or slow X.25 performance, this invalid reference may modify critical data, causing unpredictable results. [CSCdi17688]
- Bridged IP packets for router management are sent with the wrong size. If you are bridging IP and using IP for router management, packets sourced by the router for the second Frame Relay bridge entry are truncated. [CSCdi18862]
- Cisco routers with an ISDN BRI interface running the basic-dms100 or basic-ni1 switchtype may have B-channels become unavailable for usage. This may occur if there are long dialing delays for outgoing calls through an ISDN network. Also, when a call is connected on Channel B2 and the dialer idle timer attempts to hang up the call, the B-channels may become stranded and unavailable for usage. [CSCdi19671]
This section describes possibly unexpected behavior by Release 9.17(8). Unless otherwise noted, these caveats apply to all 9.17 releases up to and including 9.17(8). For additional caveats applicable to Release 9.17(8), see the caveats sections for newer 9.17 releases. The caveats for newer releases precede this section. This section includes only the most serious caveats; use UniverCD or access CIO to see all the caveats for this release.
All the caveats listed in this section are resolved in release 9.17(9). Note that, in general, most of these bugs were also resolved in Release 9.1(11).
- If source-route bridging is used, the LAN Network Manager functions such as CRS, REM, and RPS are automatically turned on. An error in the system code causes rapid accumulation of small buffers. The workaround is to put the configuration statement no lnm crs. [CSCdi16384]
- When remote source-route bridging is enabled between multiple peers, one or more of the peers may be stuck in REMOPEN state. This is observable via show source-bridging. The correct behavior is to transit from REMWAIT to OPEN state. [CSCdi17149]
- When transparent bridging is enabled Multibus Token Ring cards, the monitor bit is not cleared in the token when the packet is flooded to another Token Ring interface. The Active Monitor on the destination ring will see this bit set, assume the packet has already passed around the ring, purge it, and reissue a new free token. The workaround for this problem is to add a static bridge table entry for each destination address, for example, bridge 1 addr 0208.6ce2.088e forward t 0. Note that the address must be in Ethernet canonical format. This ensures that packets destined for this address will not have to be flooded via transparent bridging. This problem may not happen consistently, since the location of the Active Monitor on the destination ring may change over time. [CSCdi12451]
- When setting queue limits on any interface, the ciscoBus complex resets itself. This causes Token Rings to reinitialize. [CSCdi17646]
- At system boot time, TACACS code dies because it fails to establish a UDP socket with which to talk to the TACACS server. [CSCdi17830]
- When using the printer option for a TCP-LAT translation, one packet erroneously remains in the input queue on the receiving interface for each translation attempt that fails. [CSCdi17681]
- Disabling vines split-horizon does not allow VINES StreetTalk broadcasts to be forwarded out an interface that they were received on. This breaks "hub-and-spoke" Frame Relay networks, because spoke StreetTalk broadcasts are not forwarded from the hub router to other spoke sites. [CSCdi17488]
- Configuring SMDS on serial lines that are shutdown and subsequently reenabling them can in some circumstances cause a reload. A Token Ring interface appears to be required to trigger this problem. [CSCdi15880]
- X.25 calls received on a serial interface cannot be routed to a CMNS host. [CSCdi17212]
- Fast switching of IP over PPP is not disallowed for DDR. This prevents the idle timer to be reset when packets go through. Eventually the idle timer expires and the connection is torn down, even though traffic is still going through. The workaround is to explicitly disable fast switching on the DDR interface. [CSCdi17683]
- After ISDN DDR connection is already established, sometimes the line gets a DISCONNECT message from the remote end and the line drops. The only way to get the line back to where you can redial the distant end is to issue a clear int bri 0 command.[CSCdi17908]
- A router with an ISDN BRI configured for the basic-1tr6 switch type may have problems connecting on Channel B2. An incoming SETUP message using Channel B2 can be incorrectly answered using Channel B1. This may cause the PPP protocol to keep the BRI channel interface in a Protocol-Up and Line-Down situation. It will also prevent the B2 channel from receiving any more calls. [CSCdi18562]
This section describes possibly unexpected behavior by Release 9.17(7). Unless otherwise noted, these caveats apply to all 9.17 releases up to and including 9.17(7). For additional caveats applicable to Release 9.17(7), see the caveats sections for newer 9.17 releases. The caveats for newer releases precede this section. This section includes only the most serious caveats; use UniverCD or access CIO to see all the caveats for this release.
All the caveats listed in this section are resolved in release 9.17(8). Note that, in general, most of these bugs were also resolved in Release 9.1(10).
- The zone list presented to an AppleTalk Remote Access client may omit valid zones names. [CSCdi16652]
- Ethernet frames containing an invalid LLC header length and a DSAP equal to 0xF4 or 0x7E cause memory corruption and cause the system to reload. [CSCdi15699]
- When changing the bridge number of an SRB interface using LAN Network Manager platform, the router crashed. [CSCdi16403]
- The MTU of a BRI cannot be increased. [CSCdi14913]
- OSPF does not sufficiently validate received data, which in some cases can cause system failure. [CSCdi16521]
- When an interface goes down, the system fails to poison the corresponding subnet route in RIP or HELLO routing advertisements sent out other interfaces that are part of the same major network number. The system also fails to poison a network summary route advertised by RIP or HELLO to other networks. The result is that adjacent routers must time out the corresponding route in their tables, instead of being notified of the routing change immediately. [CSCdi16698]
- VINES may not work properly on CTR interfaces that are also part of a transparent bridge group. [CSCdi16797]
- When bridging over Frame Relay, data may be sent on inactive DLCIs. [CSCdi13429]
- The system fails to reply to a DO TIMEMARK when translating from Telnet to X.25. This may result in a Telnet session hang between the router and the machine sending the DO TIMEMARK. [CSCdi16405]
This section describes possibly unexpected behavior by Release 9.17(6) that has been resolved in Release 9.17(7). Unless otherwise noted, these caveats apply to all 9.17 releases up to and including 9.17(6). For additional caveats applicable to Release 9.17(6), refer to the caveats listed in the preceding section. This section includes only the most serious caveats; use UniverCD or access CIO to see all the caveats for this release.
All the caveats listed in this section are resolved in release 9.17(7). Note that, in general, most of these bugs were also resolved in Release 9.1(9).
- Gleaning of MAC addresses from AppleTalk Phase 2 packets does not work properly on Token Ring and FDDI interfaces. A low impact workaround is to disable gleaning by issuing the command no apple gleaning on the affected interfaces. It may also be necessary to clear the AARP cache to flush out any corrupt entries. This may be done by issuing the EXEC command clear arp. [CSCdi14227]
- When NBP BrRq and NBP FwdReq packets are converted to NBP LkUps, the source address is not preserved. This can cause access groups to inadvertently filter out the LkUps. The workaround is to disable access groups. [CSCdi14245]
- Devices that perform gleaning of MAC addresses from AppleTalk Phase 2 packets may experience connectivity problems. This problem can manifest itself as services on the local network appearing and disappearing in Mac Choosers. There is no workaround. An upgrade is necessary. [CSCdi14732]
- The router apparently ignores the command decnet routing-timer xxx and sends Level 2 routing updates at a higher interval. [CSCdi12802]
- When a bridge number of a Token Ring interface is changed using LAN Network Manager, the output of show source still displays the old bridge number. [CSCdi14351]
- Async interfaces running CSLIP (9.1) or PPP with TCP header compression (9.21 only) can experience UART underruns during TCP packet decompression. This can cause damaged packets which must later be retransmitted, resulting in significant performance degradation, especially on upload traffic. [CSCdi13944]
- After an uptime of nearly 25 days the IS-IS level 2 LSP may stop being sent, causing the IS-IS routing entry to disappear in the neighbor router. This is likely to happen if a router has only one level 2 adjacency. [CSCdi13482]
- In a topology where multiple equal cost routes exist to a destination and novell maximum-path is still at the default value of one, a situation can happen such that an old route-cache entry exists pointing to a route that no longer exists. Using a nondefault value of novell maximum-path will avoid this issue, which will clear itself the next time the route cache changes, or when a clear novell cache is done. [CSCdi14410]
- The XNS router process can consume excessive CPU time if it is running when no interfaces are configured with XNS networks. The simple workaround to this problem is to turn off XNS routing with the command no xns routing if no interfaces are currently configured with XNS networks. [CSCdi14948]
- Novell IPX "flash" poison SAPs received are not propagated out onto other interfaces as quickly as they should be propagated. Novell services in the SAP table should not be allowed for devices on networks for which the router does not have entries in the routing table. [CSCdi15324]
- Prior to software version 9.1(4.1), problem CSCdi01624 (X.25 switching over TCP does not convey window and packet information) required, for correct operation, that all Cisco interfaces routing via a TCP connection be configured with the same default flow control values (that is, window sizes and maximum packet sizes; parameters win, wout, ips and ops). This is because the receiving router may not be able to determine what flow control values apply to the VC. The design of Cisco's X.25 routing capability requires that, for proper operation, both ends of the VC have complimentary flow control values. With the resolution of CSCdi01624, it was decided that CALLs received on a TCP connection that do not indicate one or both of the flow control facilities should have the universally acceptable value(s) (that is, window sizes of 2/2 packets and maximum packet sizes of 128/128 bytes) forced onto the connection and indicated on the CALL CONFIRM returned over the TCP connection. While the decision to force the universally acceptable values on a connection with unknown values should offer correct X.25 operation for all connections (albeit with possibly degraded performance), it does create a migration problem for those routers running pre-9.1(4.1) software connecting X.25-capable equipment that cannot accept flow control values in the CALL CONFIRM. Configurations that once worked may no longer work when the far end is upgraded to 9.1(4.1) or better, because if the parameters indicated on the CALL CONFIRM from the far end do not match the interface defaults, the router will include them in the CALL CONFIRM to the equipment that then CLEARs the CALL because of its inability to modify the connection flow control parameters. To address this migration issue, a switch has been added to the global x25 routing command--this switch, which takes the form x25 routing TCP_USE_IF_DEFS, will cause the router to force the outgoing interface defaults into the CALL CONFIRM sent back over the TCP connection. The pre-9.1(4.1) software, then, should remove these values from the CALL CONFIRM sent to the connecting equipment. Note, however, that if the forced values do not match the interface defaults that the values should still appear in the CALL CONFIRM and cause a CLEAR, which is preferable behavior to setting up a connection with mismatched values which may cause far more subtle and mysterious misbehavior. [CSCdi13759]
- Due to a parsing error, the interface subcommand frame-relay lmi-type ANNEX D is not accepted. This occurs even when the system is reading a configuration file written by the software, as from nonvolatile memory. A workaround is to load a configuration file at boot time containing the alternative form, frame-relay lmi-type ansi, which is accepted. [CSCdi15175]
This section describes possibly unexpected behavior by Release 9.17(5) that has been resolved in Release 9.17(6). Unless otherwise noted, these caveats applied to all 9.17 releases up to and including 9.17(5). For additional caveats applicable to Release 9.17(5), refer to the caveats listed in preceding sections. This section includes only the most serious caveats; use UniverCD or access CIO to see all the caveats for this release.
All the caveats listed in this section are resolved in release 9.17(6). Note that, in general, most of these bugs were also resolved in Release 9.1(8).
- When converting NBP BrRq packets into NBP FwdReq, the system does not preserve the original DDP source address. It, instead, uses the address of the outgoing interface. This can short-circuit access-group filtering. [CSCdi13287]
- Multipacket responses to requests (RTMP Route Data Requests and ZIP GetZoneLists, for example) can be partially lost if no AARP entry exists for the requesting node. A workaround is to populate the AARP cache before the request; sending a ping packet from the requestor will suffice. Alternatively, send the request twice. [CSCdi13758]
- Possibly due to a condition where all valid interfaces are in a down state, TACACS (or SYSLOG, or other datagram-oriented protocols running above IP) may begin sourcing packets from a downed interface. This situation can be verified with the show ip sockets command. It can be remedied by shutting down an interface (which may already be shut down). A workaround is to assign an IP address to the loopback interface. [CSCdi12845]
- DECnet does not accept HELLOs from nodes with node-address greater than the max-address configuration parameter if the HELLO contains an area address which is different from the router's area address. [CSCdi13136]
- After power-cycling, RSRB peers may not renegotiate properly. The state will be OPEN, but no traffic will pass. [CSCdi12749]
- The ethernet-transit-oui standard command does not function as described in the manual for 8209 compatibility. When going from Token Ring to Ethernet, with the ethernet-transit-oui command on the Token Ring interface, the router should convert all frames to Ethernet II frames, regardless of the SNAP OUI field. Instead, frames with an OUI of 000000 (all frames from an 8209) are translated to an 802.3 frame with the SNAP header intact. [CSCdi12844]
- If unexpected input in an SDLC connect state occurs, the input interface can lock up after a while. If you turn on debug sdllc and watch state transitions of the SDLC lines you will see exception conditions causing state transitions from a CONNECT state (CONNECT, USBUSY, and so forth) to DISCONNECT and then back up. Further you will see the input hold count on the input interface rising. When it reaches its maximum, all input to this interface will stop including other PU traffic (associated with this serial interface). [CSCdi13441]
- Two RSRB peers are running with local acknowledgment turned on (either RSRB/LA or SDLLC/LA). If one of these routers reboots, it can come up so fast that the other router fails to time the other peer out and the peer reconnects. In doing so the local acknowledgment sessions will get out of sync. There is no workaround. This fix is required and will cause any local acknowledgment sessions to be reset upon a reconnect from a rebooted router. [CSCdi13677]
- An unterminated Ethernet connection on a system with FCIT and ciscoBus 2 controller may result in a reset of the ciscoBus. [CSCdi13045]
- When using encapsulation bridging over FDDI, bridged frames input on Frame Relay interfaces are incorrectly forwarded onto the FDDI interface using an FDDI multicast address rather than the correct FDDI unicast address. [CSCdi13412]
- An unterminated Ethernet cable on a ciscoBus complex such as the MEC or a CxBus complex such as the EIP causes the bus to reset and returns the error code 800E. The workaround is to shut down the Ethernet interface in question so that the other interfaces do not also reset. The fix to this problem is to automatically shut down the Ethernet interface to which the unterminated Ethernet cable is attached. This prevents the interfaces on the bus from resetting. Once the Ethernet cable has been properly terminated and reconnected, you need to issue the no shut command on the Ethernet interface to restart it. However, the message "Interface x output hung" still is inadvertently sent to non-Ethernet interfaces. [CSCdi13502]
- After a reload, an OSPF area border router fails to advertise some networks over an X.25 network. The workaround is to do a shut/no shut of the X25 interface. [CSCdi13027]
- In some cases, taking down an adjacent OSPF peer may cause the router to reload. [CSCdi13736]
- If the Novell routing information is displayed while in the process of being updated, then the system may reload. [CSCdi12736]
- When responding to a RIP request from a NetWare 3.1x/4.x server/router, the response is sent to an incorrect MAC address (0000.0000.0001) and therefore is never received. This will happen only on NetWare devices that use an internal network number. [CSCdi13400]
- This problem only occurs when a network containing servers is configured as a serverless network. Packets received on this interface that are passed through the helper code may not be returned to the free buffer pool, eventually causing the interface to stop receiving because it has exceeded the input queue count. This problem is only evident in maintenance releases 9.1(6.1) through 9.1(6.5). [CSCdi12842]
- The fix submitted for CSCdi12849 is incomplete; X.25 INTERRUPT packets are still mishandled in switched VCs. [CSCdi13369]
This section describes possibly unexpected behavior by Release 9.17(4) that has been resolved in Release 9.17(5). Unless otherwise noted, these caveats applied to all 9.17 releases up to and including 9.17(4). For additional caveats applicable to Release 9.17(4), refer to the caveats listed in the preceding sections. This section includes only the most serious caveats; use UniverCD or access CIO to see all the caveats for this release.
All the caveats listed in this section are resolved in release 9.17(5). Note that, in general, most of these bugs were also resolved in Release 9.1(6) or 9.1(7).
- DECnet was sending L2 updates starting with area number zero. This upset DEC routers, since valid DECnet areas start from 1. [CSCdi09981]
- When a Phase IV node initiates a connection to a Phase V cluster alias the connection fails. The router has incorrectly obtained Phase IV adjacency information from the Phase V cluster hellos and forwards packets with Phase IV (DECnet) encapsulation. [CSCdi10436]
- A router running with IV/V conversion enabled converts any Phase IV hellos it receives and adds it to the Phase V adjacency database. The format of this entry in the Phase V database is recorded as "Phase IV". If a corresponding Phase V hello comes in (that is, the other router is also running Phase V), it should overwrite the entry in the Phase V adjacency database that was always forwarding to the final destination instead of the next hop. A IV adjacency is stored in the V adjacency database as noted above. This information also is entered into the Phase V routing table, so that it is propagated through the OSI cloud. The caveat results in the router not updating this route, so the route would go into holddown and ultimately go away. Therefore, Phase IV ES information never stays long enough in the V routing table. [CSCdi11174]
- All data structures used by the show routines are locked to avoid a premature free of that chunk of memory. This chunk of memory is freed at the end of the show routine. There were code paths where the show function could return, without freeing the locked chunk of memory. This could lead to memory leaks. [CSCdi11545]
- The no exec-banner command is documented in the router software manual, but is in fact only implemented on communication servers. [CSCdi11290]
- The system did not learn the burned-in address of the Token Ring adapter card until after the interface inserted onto the ring. If the interface was shut down when the router was booted and the router was configured for bridging, the virtual ring address would be configured with the address 4000.0000.0000, which is clearly invalid. This happened because the virtual ring uses the burned-in address of the adapter, logically ORed with the 4 to obtain its unique address, which is a problem in the above scenario. [CSCdi07105]
- Under heavy traffic loads, the SDLC T1 timer may expire prematurely. This may manifest in multidrop circuits where the T1 timer has been set to a value of 1. The cause of the problem has been determined to be the delay between the time the T1 timer is set in the system software and the time the packet actually is sent out on the line. As packets get queued up at the interface, this delay becomes significant. Modification has been made in the system software to resolve this problem. The user must now specify the interface subcommand line-speed to compensate for this delay.
[no] sdlc line-speed rate
- where rate is in bits per second. For DCE, this should be the same as the clockrate on the interface. For DTE, this should be the clockrate on the DCE device to which DTE is connected. [CSCdi09719]
- The Token Ring interface was sending ring status messages to the LAN manager when it was in the DOWN state. The status messages are valid only after the interface has begun the insertion process. [CSCdi10364]
- The LLC2 and SDLC sessions of the downstream router hang when the upstream router of a SNA link configured with SRB/SDLLC and local acknowledgment is power-cycled. The show llc2 and show interface commands on the downstream router will provide erroneous display of the LLC2 and SDLC sessions. The workaround is to reload the downstream router. [CSCdi10477]
- When using SR/TLB to forward NetBIOS traffic, a large number of "frames too large for transparent" bridging counts may be seen going from Token Ring to Ethernet. This is most likely due to NetBIOS end stations ignoring the "largest frame" parameter of explorer replies. The workaround is to bring the largest frame size on the Token Ring end stations down to 1470 bytes in order to forward frames onto an Ethernet interface using SR/TLB. [CSCdi10506]
- The router would reload with the error message of "restarted by bus error at PC 0x1ADF00." This points to the local acknowledgment routine. Turning off local acknowledgment functions as a workaround. [CSCdi10718]
- If a server was rebooted, it would complain about duplicate server names on the net. When the RIF times out, it would be able enter the ring. In an RSRB environment with duplicate routers on a single ring, within the same ring group packets can be placed on the ring from which they came. The routers need to have remote peer statements to each other and also have proxy explorer enabled to cause this problem. The workaround is to turn off proxy explorer, and the solution is to upgrade to 9.1(6) or above.[CSCdi11016]
- SR/TLB in a Token Ring to FDDI to Token Ring environment had a number of problems. First the FCIT card has a feature that reduces TX underruns, but causes 16-byte frames such as a SABME to get lost. This causes connectivity for NetBIOS and any other LLC2-based protocol not to work. In addition, the LF bits negotiated on the Token Ring were too large, causing packets larger than 1500 bytes to get dropped. Note that the Cisco 7000's FIP did not have the first problem but did have the others. [CSCdi11186]
- The 3174 control unit cannot connect to the host. The message "SDLC: Cannot get memory for timer RR packets. SDLC dying." is displayed on the router console. The show interface command for the SDLC line displays the interface state of SNRMSENT and AWAITING CONNECTION but the 3174 does not connect. The workaround is to reload the router. [CSCdi11509]
- If the IP MTU is set to less than the interface MTU, packets will be process-switched rather than fast-switched. [CSCdi09453]
- When bridging between more than two locations on X.25 (that is, multiple x25 map commands), multicasts on some logical channels have the Ethernet header (addresses and type) truncated. Unicasts are not effected by this problem. There is no workaround. Users encountering this problem are advised to contact the Cisco TAC for upgrade information. [CSCdi10063]
- When bridging over circuit groups, all broadcast traffic was forwarded over one of the line in the circuit group instead of being load-balanced. [CSCdi10071]
- In software release prior to 9.1(5.4), the router will block the data path for longer than required during reboot or interface reset and cause downstream neighbor(s) beaconing. The workaround is to insert the router to the ring (plug the fiber cables) after the booting, and the solution is to upgrade to 9.1(5.4) or later. This requires a ROM software upgrade. [CSCdi10106]
- When using the output-address-list command, the bridge table may fail to be updated when a node moves from one interface to another. [CSCdi10519]
- This problem can be identified with the output of show memory. The I/O memory will be found to be steadily decreasing. In addition, the output of show buffers will also show a large number of big buffers being created. There is no workaround; however, increasing the number of big buffers will delay the memory loss. [CSCdi10586]
- The source-bridge proxy-explorer command will cache invalid RIFs to all routes explorers. The problem occurs only if source-bridge proxy-explorer is configured on Token Ring and if the explorer type is all routes broadcast. This command is disabled by default. The workaround is to turn off source-bridge proxy-explorer. The symptom of this problem can be seen in the router's RIF entry. A show rif command will display the RIF cache and there will be invalid bridge and ring numbers in the RIF field. [CSCdi10750]
- The Token Ring interface reinitializes after buffer starvation. The symptom is that show interface txx shows input queue at 76/75. [CSCdi11032]
- There is a window in which commands to the interface get dropped. The fix is to protect against interrupts when issuing commands. In this case, the system drops the command to throttle the interface. When the system later tries to unthrottle the interface it can get passed random pointer values to the interfaces shared memory. Also, store the throttle count in idb and display in show controller. [CSCdi11046]
- The router may fail to bridge certain protocols upon initial startup. Reloading the router will correct this condition. [CSCdi11480]
- The bridge is not forwarding broadcast packets over a bridge circuit group. The packets propagate on both serial links, but are blocked at the second serial interface on the other end. The show span command will display that the second interface is in the blocking state. [CSCdi11811]
- In certain environments, the use of source-bridge proxy-explorer may cause a router to reload, reporting a "Jump to Zero" error. [CSCdi12328]
- The fast-switching cache for IP is invalidated frequently. This results in lower than expected performance for IP routing and high CPU utilization. [CSCdi10811]
- Under certain unknown but infrequent conditions the memory pool may get corrupted, causing the router to reload because of lack of memory. A show memory command prior to reload will show substantially less than expected memory in the Total Bytes column. [CSCdi11392]
- Changes made to support the AutoInstall feature may result in the router displaying console messages such as "Booting network-confg...". These messages are cosmetic only. [CSCdi12394]
- Under extreme circumstances if autonomous switching is enabled (that is, ip route-cache cbus is configured), the router will reload. This is most likely to occur when the tables used to maintain the autonomous switching cache grows to a large size. One condition that could aggravate this are very large numbers of hosts on a single interface. [CSCdi12415]
- When an interface is shut down on a router running OSPF, the OSPF process will try to learn the routes through a different interface. This results in a very high CPU utilization on the router (above 95%) for a few minutes until the SPF algorithm has recalculated all the routes. [CSCdi10108]
- In OSPF routers, the area area-id stub command causes the router to loose neighbors. [CSCdi10295]
- On Cisco routers with Token Ring interfaces, enabling OSPF using the following commands may cause the router to execute an immediate system reload: [CSCdi10488]
router ospf ospf-process-id
network address wildcard-mask area area-id
- When RIP is turned on a connected route and RIP routes are redistributed into OSPF, the connected route is not redistributed into OSPF routes after shutdown and no shutdown is executed on that interface. [CSCdi10957]
- If many hundreds of subnets are being transmitted via IGRP, the IGRP routing process can detrimentally impact the performance of other portions of the router. The symptom generally seen are extremely long delays through the router when routing updates occur. [CSCdi11284]
- OSPF sets the forwarding address when the next hop is through an unnumbered serial interface. This points to an address in the external Link State Adjacency (LSA) that may or may not be in the OSPF domain. [CSCdi11583]
- The router will reject IS-IS packets when more than one SNPA with the same address is present in the CLNS neighbor table. This can be determined with the EXEC command debug clns-routing. [CSCdi10931]
- The router may reload if more that one IS-IS PSNP/CSNP is sent. [CSCdi10939]
- IS-IS hellos possibly appear to be causing an input queue to wedge. Removing IS-IS from the interface and reloading clears the problem. [CSCdi10948]
- When clns route-cache is enabled (default) and a DECnet Phase IV adjacency has been established, it is possible for the Phase IV-Phase V conversion routine to forward Phase V packets (CLNS) to the Phase IV end system. This would result in a loss of connectivity when the Phase IV end system is attempting to connect to a Phase V host. Turning off the CLNS route cache via the interface subcommand no clns route-cache will act as a workaround, but may negatively impact performance. [CSCdi10980]
- CLNS pings do not work to a Token Ring interface. [CSCdi11265]
- The formula for metric calculation was not correct; in particular, setting K4 to zero and K5 to 1 would make the denominator of the expression to be zero, causing a "zero error divide." [CSCdi11705]
- XNS network numbers greater than 2147483648 are displayed as negative numbers by the various write commands. [CSCdi10510]
- The SAP Flash updates that result from adding a static SAP to a router are not filtered according to any assigned SAP filter list. SAP poison packets, hop count 16, are not filtered according to the configured SAP filter access list on the outgoing interface. Static SAP entries are Flash-announced to the world at the wrong hop count; when the correct hop count is sent in the periodic updates it will cause neighbor routers to think the topology has changed and to place the service into hold down, timeout, and Flash an advertisement of hops equal 16 before advertising the correct hop count. [CSCdi10834]
- When an interface goes down the directly connected network assigned to that interface, using the novell network command, the interface should be removed from the routing table and not go into holddown for three minutes. [CSCdi10886]
- When bringing up an interface that has been down since system startup, on a router running with xns ub-emulation configured for over four weeks, the newly installed XNS interface will not send out UB XNS RIP packets after the initial update at interface startup. A workaround is to briefly turn off xns ub-emulation and then turn xns ub-emulation back on. This may cause a couple minutes of UB route disruption on routes using this router. [CSCdi11543]
- When applying an extended access list, packets using IPX packet type 4 (PEP) are forwarded only when there is already an entry in the IPX route cache for this IPX destination. If there is no entry or if IPX route caching has been turned off, no frames are forwarded. The access list itself works fine, but devices trying to communicate using PEP-packets seem to get filtered. [CSCdi11730]
- There exists a condition which may cause a system reload if a Novell or XNS route is being removed from the routing table at the same moment the show novell route or show xns route is accessing that information from the routing table. [CSCdi12101]
- If a Novell SAP update is received which has more than the normal seven services per frame advertised and all those services are new, there is a strong possibility that memory will be corrupted. [CSCdi12108]
- The optional behavior of the novell rip-check command installed as of CSCdi09056 has now become the default. To turn off the RIP check handling of RIP requests use the no novell rip-check command. Two new counters have been added to the show novell traffic display: SAP format errors and RIP format errors.Should these counters be incrementing on a router, it might be prudent to investigate which client is sending malformed RIP requests by turning on debug novell-rip-event; information will then be displayed about the next one of these packets which arrives along with other RIP events that may or may not be interesting. Note: turning on debugging may cause unwanted overhead on the router; use of an analyzer may also be warranted. [CSCdi12244]
- Frame Relay is not checking the proper bit for FECN. [CSCdi10739]
- This fixes a bug where the SMDS PAD bytes were being fast switched to the next hop interface as garbage bytes. For IP this was not a problem since the true PDU length is in the IP header, but it does cause an additional 0 to 3 bytes to be added to each fast-switched packet. [CSCdi11015]
- For encapsulation ddnx25, DDN Precedence facility is allowed in X25 CALL CONNECTED frames. The DDN Precedence (or absence) must agree with that of the X25 CALL REQUEST frame. [CSCdi11405]
- The M bit is set improperly in the last packet when the packet is full but no additional data to be sent. [CSCdi12080]
This section describes possibly unexpected behavior by Release 9.17(3) that has been resolved in Release 9.17(4). Unless otherwise noted, these caveats applied to all 9.17 releases up to and including 9.17(3). For additional caveats applicable to Release 9.17(3), refer to the caveats listed in the preceding sections. This section includes only the most serious caveats; use UniverCD or access CIO to see all the caveats for this release.
All the caveats listed in this section are resolved in release 9.17(4). Note that, in general, most of these bugs were also resolved in Release 9.1(5).
- Under certain conditions, the configuration interface subcommand multiring all or multiring appletalk will prevent the router from being able to acquire an AppleTalk node address, thereby preventing the interface from coming active as a routing node. This condition can be detected using the debugging command debug apple-arp which will show the router attempting to probe for an address indefinitely, incrementing the requested node address at each cycle. This condition can be circumvented by removing the multiring command from the afflicted interface (multiring is only necessary if AppleTalk traffic will be source-routed from the adjacent Token Ring to remote Token Rings). If multiring is necessary, a temporary workaround is to disable multiring only during the AppleTalk ARP process. Once the interface has become operational for AppleTalk, multiring can again be applied to the interface. However, if the interface should restart for any reason, AppleTalk will again be disabled, so this should be considered an emergency workaround only. [CSCdi09753]
- AppleTalk packets cannot be fast switched between MEC Ethernet controllers and HSSI serial controllers when the Ethernet interface is running Phase I AppleTalk, and the HSSI interface is running Phase II AppleTalk. This problem will be fixed in a future release. [CSCdi09818]
- Under unknown circumstances, entering the show process command can cause the router to reload. [CSCdi09760]
- When a Cisco router with multiple Token Ring interfaces runs with the DECnet protocol, there are duplicate Token Ring MAC addresses on the bridge network because Cisco implementation of DECnet modify all the Token Ring interface MAC addresses to the same address. The IBM LNM protocol does not allow multiple stations with the same MAC addresses to exist on the bridge network. All the LNM functionality that relates to the duplicated MAC address will not perform normally, like path-test, station profile, and link-with-bridge. A configuration command is added to allow an LNM module in a Cisco router to accept link-request from the adapter that is not closer to the LNM station ring. In a normal case, LNM station links with the adapter of a bridge that is closer to the LNM ring, and expects to receive an error if LNM station try to link with the other end of a bridge. This addition allows a Cisco router to stay linked with LNM station and report problems, but other LNM station-related functionality still does not act properly.
- The following is the procedure to configure the router and LNM station:
- 1. Define the Cisco router as a bridge on the LNM station using the burn-in address and virtual interface address.
- 2. Issue the lnm duplicate-address global configuration command on the Cisco router to turn on the option. [CSCdi09396]
- A TCP connection that has transmitted a very large amount of data (on the order of 2 billion bytes) can remove packets from the retransmission queue prematurely, causing the connection to unexpectedly close due to a retransmission timeout, even though the network path is working correctly. This can affect router functions like remote source route bridging, which can transmit large amounts of data over a long period of time. [CSCdi09764]
- In the function for dealing with ring status messages there is a test for the state "DOWN" that declares the interface "UP", the assumption being that the interface does not issue ring status messages until it's inserted onto the ring. This is a breach of the keepalive process and preempts an attempt to put the ring into state "TESTING". The offending code has been removed. [CSCdi09742]
- While priority queuing with the input interface being serial and the output interface being serial, the first 4 bytes of the destination MAC address are munged. The workaround is to disable priority queuing if possible. [CSCdi09799]
- When bridging AppleTalk Phase II (802.3 SNAP encapsulation) and using LSAP filters to specify SNAP encapsulated packets (access-list 201 permit 0xAAAA 0x0000 for example), AppleTalk Phase II packets fail the access control and are dropped. A temporary workaround is to permit all SNAP frames using a modified filter (access-list 201 permit 0x0000 0xffff, for example) and then use a type filter to further restrict the desired traffic. [CSCdi10062]
- Source-bridge proxy explorer will cache invalid RIFs to all routes explorers. The problem occurs only if source-bridge proxy-explorer is configured on token-ring and if the explorer type is all routes broadcast. This command is disabled by default. The workaround is to turn off source-bridge proxy-explorer. The symptom of this problem can be seen in the router's RIF entry. A show rif command will display the RIF cache and there will be invalid bridge and ring numbers in the RIF field. [CSCdi10750]
- Under unknown circumstances, the router can execute a system reload when HIP interfaces are inserted. The router will boot normally after the reload. [CSCdi11139]
- When the system attempts to add connected routes for an interface's primary and secondary IP addresses, it may fail to add some of the routes for the secondary addresses. This failure occurs if the interface changes from an up to down state while the system is in the process of establishing the connected routes for the interface. This problem is most readily seen when these connected routes pertain to an FDDI interface, and OSPF is being used. The user may need to defer the specification of the interface's secondary IP addresses until the interface's state has stabilized. [CSCdi09744]
- The problem was that the LAN Network Manager "frame forward" used to verify an SRB route was causing a call to the function "send_trace_report( )" with parameters in reverse order. This caused an attempt to jump to a null vector, thus "jump to zero error." The patches not only fix the function call, but also put in paranoid code to check for invalid pointers. [CSCdi09980]
- If two routers exchange an external BGP route over IBGP and that external route is removed, the routers can converge on the IBGP route. This forms a static routing loop. This behavior was introduced in 9.1(4.5). [CSCdi10733]
- When CLNS receives a packet that needs to be fragmented, but the "segmentation permitted" bit in the packet is off, it should send back an error packet (ERPDU) indicating this situation. [CSCdi09413]
- Novell encapsulations other than the system defaults on Token Ring or FDDI interfaces are not written out in the write term, write network, or write memory commands. If the Novell encapsulation on Token Ring or FDDI is changed from the default, it will revert to the default Novell encapsulation after the next system restart. [CSCdi09892]
- When fast switching from SBE Token Ring interfaces to HDLC encapsulated serial interfaces, the last 7 bytes of data in an odd-length frame and 8 bytes of data in even-length frames will become corrupted. Turning off Novell route-cache on the output serial interface will allow the frames to be forwarded properly. [CSCdi10230]
- XNS RIP General Request replies have the split-horizon rule inadvertently applied to them. Split horizons should not be applied to XNS general request responses. [CSCdi10294]
- When a TCP connection has a closed window, packets containing valid ACKs are discarded if they also contain any data (since the data is outside of the window). The correct behavior is to continue to process the ACKs for segments with reasonable ACK values. This is especially a problem in the initial stages of a connection, when we send the SYN-ACK with a 0 window. If the ACK to our SYN contains data also, we will not process that ACK, and the connection never gets to the ESTABLISHED state. [CSCdi05962]
- Telnet connections to a router will not transfer any data during the first couple of seconds after a connection is first opened, resulting in a visible pause if the user begins typing immediately. [CSCdi09576]
- The fix for CSCdi10017 broke the hangup process. It is now fixed. [CSCdi10351]
This section describes possibly unexpected behavior by Release 9.17(2) that has been resolved in Release 9.17(3). Unless otherwise noted, these caveats applied to all 9.17 releases up to and including 9.17(2). For additional caveats applicable to Release 9.17(2), refer to the caveats listed in the preceding sections. This section includes only the most serious caveats; use UniverCD or access CIO to see all the caveats for this release.
All the caveats listed in this section are resolved in release 9.17(3). Note that, in general, most of these bugs were also resolved in Release 9.1(4).
- More than one X25 MAP AppleTalk entry crashed the router. The cause of the crash was an infinite recursive call loop (x25_doencaps( ), x25_encaps( ), x25_vencapsulate( )). This error was introduced by CSCdi03774 (AT fixes & cleanup). x25_doencaps( ) will call x25_broadcast( ) repeatedly unless pak-atalk_dstmast != ATALK_UNICAST is done in x25_broadcast( ) for AppleTalk to undo pak_duplicate( ). [CSCdi09328]
- The show diagbus command has been extended to print out the onboard EEPROM information for the RP as well as the SP and IPs. The user interface remains the same. [CSCdi09073]
- If dialer interfaces are created using the interface dialer n command, they can never be deleted from the configuration. [CSCdi07979]
- Misconfiguration of the router with peers that don't exist or are powered down can cause the box to lose all memory. [CSCdi09041]
- RSRB peers that use TCP used to rely on the TCP transport to inform it that the remote side has gone away. The problem with this is TCP can take a very long time to time out. This isn't acceptable in the IBM environment. We've implemented the concept of remote-peer keepalives that ensures that the other side is healthy. Messages are only sent if there is not other traffic. [CSCdi09596]
- In bridge tables with large numbers of entries or more than one bridge group, dynamic station entries may appear with an "S" in the Age field. These entries will then not be properly aged or relearned. This may result in a station being unreachable from a bridge should the spanning tree reform. These entries may be removed manually using the no bridge group address MAC-address command. This action will allow the entry to be relearned. These entries can be removed from the bridge table as a whole only by reconfiguring the affected bridge group. Cisco Systems expects to resolve this behavior in a future release. [CSCdi08239]
- The VINES protocol fails to run over an FDDI interface configured for transparent bridging. Routing information passes in only one direction across the FDDI link. There is no workaround to this problem yet. Routing VINES across FDDI links is not affected by this problem. This caveat was introduced in the 9.1(0.24) release. This caveat has been resolved in release 9.1(1.4). [CSCdi08288]
- If an async interface is unnumbered, and an IP address is assigned from the exec, then the async interface should not be renumbered. If SLIP routing is started, but the address does not belong to the subnet that is already configured on the terminal servers primary interface, the address will be rejected. [CSCdi08621]
- Transparently bridging on a serial interface and turning on priority queuing, X.25, or Frame Relay encapsulation causes a packet to be tossed, in effect to halt bridging. The workaround is to use different serial encapsulations and disable priority queuing. [CSCdi09489]
- Due to interactions between the bridging and driver code, the spanning tree state would be handled correctly. In pre-9.1, this would show up most readily on serial lines. If a serial line was shut and then no-shut, the port would go into blocking and then stay there. This same bug also shows up in other ways. Namely, if you have an Ethernet port and you pull the cable out, the port will go down. But if you wait for a minute or so (give the spanning tree protocol time to recompute) and then plug the cable back in, you'll see the port go into Forwarding immediately. This can cause temporary network meltdowns. [CSCdi09535]
- The active monitor of the ring is not seen at initial boot time of the router. The active monitor will be seen only if a soft error occurs on the ring. There is no workaround. [CSCdi09830]
- A router may experience large processing demands for a TCP connection on closure if the TCP protocol exchange for the close is unduly delayed. This was detected and traced in connection with Cisco X.25-over-TCP implementation where X.25 caused the connection to linger in a half-closed state. The X.25 behavior was reported and fixed as bug report CSCdi05031. [CSCdi05515]
- When a TCP connection has a closed window, packets containing valid ACKs are discarded if they also contain any data (since the data is outside of the window). The correct behavior is to continue to process the ACKs for segments with reasonable ACK values. This is especially a problem in the initial stages of a connection, when we send the SYN-ACK with a 0 window. If the ACK to our SYN contains data also, we will not process that ACK, and the connection never gets to ESTABLISHED state. [CSCdi05962]
- When using multiple addresses on a single interface from different major networks and with different sized subnet masks, sometimes an address overlap is reported where none exists. [CSCdi09104]
- Source routed IP packets which are supposed to be discarded by the system sometimes are not. Such packets are being packet switched when the local system does not appear as the next hop in the source route. These packets should never be packet switched when the user has entered the no ip source-route configuration command. This unexpected behavior can pose a security problem for sites who use this command to restrict access. Access lists can probably be used as a substitute means of restricting access. [CSCdi09517]
- There are some cases when OSPF processes the link state advertisement retransmission list, the system will reload. This happens right after the system starts up. [CSCdi04617]
- This message appears when a LAN Net Manager trace frame is accepted by the router and forwarded onto other interfaces on that router.
%SYS-2-SHARED: Attempt to return buffer with sharecount 0, prt= 365180
-process= "*sched*", ipl=4
-traceback = 60bc 14343c 15c092 7368a 72328 1798 104c 100068a
%SYS2-INLIST: Buffer in list, prt= 1ccdf8
-process = "*sched*" , ipl=4
-traceback= 6172 14343c 15c092 7368a 72328 1798 12ad68 21fc
- This causes a minor memory leak in that the wrong packet inside the router is trying to be freed. There is no workaround. [CSCdi07950]
- System normally disallows multiple interfaces to be configured with IP addresses on the same subnet. Such IP address overlap should be allowed when it occurs between a transmit only interface and its associated receive interface, as designated by the transmit-interface interface subcommand. [CSCdi09300]
- CLNS fast switching over a serial interface with HDLC encapsulation falls back to slow switching. [CSCdi09172]
- Show XNS Interface for Token Ring interfaces improperly displays XNS fast switching enabled. Token Ring XNS fast switching is not currently supported, the Show XNS Interface should display fast switching disabled. [CSCdi09288]
- There is a condition where some serverless networks will have extreme difficulty logging into any server. This is caused by a packet sent by the router not being understood by a VINES server. The workaround to this problem is to shorten the name of the Cisco router to be 15 characters or fewer. [CSCdi09372]
- This problem only occurs when a client is initially powered on, and the first login attempt results in a forced password change. The user will not be able to change their password, and will not be able to log in. The workaround is to have another user login and logout at that client, and the affected user will be able to login and change their password. [CSCdi09467]
- This patch allows fast switching of Frame Relay, HDLC, and SMDS across both serial interfaces. [CSCdi09107]
- Incorrect behavior is caused by some octets not being transferred from one MCI card to the other. This now corrected by ensuring that all octets are properly transferred across the multibus. [CSCdi09826]
This section describes possibly unexpected behavior by Release 9.17(1) that has been resolved in Release 9.17(2). Unless otherwise noted, these caveats applied to 9.17(1) and 9.17(2). For additional caveats applicable to Release 9.17(1), refer to the caveats listed in the preceding sections. This section includes only the most serious caveats; use UniverCD or access CIO to see all the caveats for this release.
All the caveats listed in this section are resolved in release 9.17(2). Note that, in general, most of these bugs were also resolved in Release 9.1(3).
- When a router is configured with an AppleTalk zone name that begins or ends with a special 8-bit graphics character, NBP lookup queries made to this zone in the router will cause the router to reload. The workaround is to not configure zone names that begin or end in 8-bit characters. A crash can also occur when a NBP search is performed with graphics characters at the beginning or end of the type field. For example, a server with a trademark symbol at the end of the server-type name will cause the router to crash if it is installed on a zone connected to the router. The workaround is to move the server to a zone not assigned to the router, so that lookups requests for this type of service will not be directed at the router. [CSCdi07672]
- When a DECnet extended access list is configured with a destination address, the code ignores the destination/mask info in the ACL. If a match was found in the connect part of the ACE, it would return TRUE, that is, would grant access, regardless of the destination/mask information. For example:
access-list 300 permit 1.400 0.0 1.999 0.0 eq any
should allow ONLY packets from 1.400 to 1.999 to go through. The observed behavior was all packets would go through, regardless of destination. The fix is to just check that the source address/mask (and destination/mask, if applicable) specified in the access list matches the corresponding values in the incoming packet. [CSCdi08760]
- The DECnet fast switching code will not process an extended ACL if no standard ACL is present. To be consistent with the slow-switched case, the check for the presence of a standard ACL should be removed, so that a list consisting of only extended ACEs will be processed. [CSCdi08875]
- Initializing Token Ring causes existing LNM link to be dropped. There is no further information available concerning this problem. [CSCdi07235]
- When the router is configured with the netbios enable-name-cache command, it does not modify the Largest Frame (LF) field within the Routing Control field of All-Routes and Spanning Tree explorer frames. Stations communicating across a source-routed network connected by routers experiencing this condition may not be able to establish a connection. Because stations do not see the LF reduced, they may transmit a frame larger than the maximum size which is capable of successfully crossing a router. The router will drop the large frame and the connection will not be established. The proper behavior is for the LF field of All-Routes and Spanning Tree explorer frames to be reduced to indicate the maximum frame size capable of being transferred across the bridge. The maximum frame size is the minimum of the frames sizes supported by the input interface, the transit media and the output interface. A workaround is to disable the NetBIOS name caching feature with a no netbios enable-name-cache command. The router will properly process and reduce the LF field with name caching disabled. The behavior is present in all versions of the router supporting NetBIOS name caching. Cisco Systems will resolve this problem in an upcoming maintenance release of 9.1. [CSCdi08170]
- A Cisco router sends VINES routing updates as spanning tree explorers whereas a VINES server sends routing updates as all-routes explorers. The Cisco implementation provides lower explorer impact upon the network, whereas the Banyan implementation finds the shortest path between any two nodes. This bug fix provides a method of choosing between spanning tree explorers and all-routes explorers on a per protocol basis. This is an extension to the multiring command. The new command syntax is:
[no] multiring ( | all) multiring ( | all) [all-routes | spanning]
The default is to use spanning tree explorers. [CSCdi09091]
- Under unknown circumstances, IP routing has a memory leak and will slowly use up all available memory on the router. [CSCdi07288]
- If a summary LSA is regenerated within 5 seconds, the flooding of the LSA may not happen resulting in inconsistent database. The fix will be available in a future release. [CSCdi08463]
- The system does not properly process RARP response packets received where these packets are responses for requests not initiated by the system. The system allows such packets to remain in the input queue, resulting in two user visible problems. First, the network interface input queue can fill up with RARP response packets, causing all subsequent packets destined for the system to be dropped. Second, the system fails to bridge these RARP response packets. The correct behavior is to bridge such packets in the case where the system is configured to bridge RARP packets, otherwise to ignore these packets. [CSCdi08651]
- The distribute-list command sometimes makes access list changes even when a parsing error is detected and an error message is printed. The software continues processing this command even though an error has been detected. Because of this aspect of the implementation, the system will treat a distribute-list command which specifies a nonexistent interface as if no interface has been specified, thus unexpectedly applying the access list to all interfaces. If the user receives parser errors in response to their distribute-list configuration commands, it is recommended that they verify that the system has not wrongly interpreted their commands by examining the distribute-list commands reported by write terminal. [CSCdi08668]
- There are some cases when OSPF processes an incoming summary link state advertisement, the system will reload. This problem occurs under heavy OSPF load conditions. [CSCdi09090]
- Certain destination addresses will not be correctly placed into the FDDI fast switching cache for XNS or Novell. As such, certain addresses will always be slow switched. This problem will be fixed in a future release. [CSCdi08373]
- When a Cisco router generates a XNS error response packet, it is sent out with a source address equal to the original source of the packet which caused the error response. The source address should be that of the router itself. [CSCdi08377]
- When fast switching Novell Ethernet frames which have an 802.3 length less than the minimum Ethernet size, the 802.3 length field is incorrectly set to 60. Some Novell hosts will then count this as an error when they receive it. The frame which might often been seen with the error would be a NetWare "Create Service Connection Reply" packet coming from a server through a Cisco to a client, if the client rejects this packet then the connection attempt fails. Only some clients and some servers will see this problem, depending on the vendor and version of the Ethernet driver on the PC. When fast switching is off we put the correct 802.3 length in the packet. This happens between any two EIP Ethernet ports in the same router, or between any two Ethernet ports on the same EIP card. [CSCdi08547]
- Certain Ethernet drivers (cards) used by workstations running Novell/IPX when using the Novell encapsulation type on an Ethernet of novell encapsulation novell-ether cannot have their packets fast switched. There are two workarounds to this problem. The first is to make the workstations use the encapsulation compatible with the novell encapsulation arpa for Ethernet interfaces. The second is to enable slow switching on the Ethernet interfaces. This compatibility issue will be addressed in an upcoming release of software. [CSCdi08577]
- Fix the Cisco router to accept and process VINES redirects from other servers. Prior to this fix, redirect messages were ignored. This patch also fixes some minor problems generating redirect messages. [CSCdi09088]
- There is a race condition where if a show dialer command is issued after the idle timer expires, but before the call is disconnected, the output may show a large negative number. Issuing the show dialer command again will show the correct value. [CSCdi06415]
- The x25 pvc bridge number interface command is not properly stored in the router's configuration memory. [CSCdi06683]
The following sections describe each revision of microcode for the Cisco 7000 series Switch Processor (SP) and for each interface processor.
Version 1.0 is the first officially released version of EIP microcode. It was released on January 25, 1993.
Version 1.1 was released on March 7, 1994.
Modifications
The following problems were fixed in this release:
- A DEC system on the Ethernet link may experience DECnet DAP CRC errors.
- At greater than 30% load, performance may drop due to retransmissions.
Version 10.0 was released on May 31, 1994.
Modifications
Version 10.0 supports the improved buffering scheme.
Version 1.0 is the first officially released version of FIP microcode. It was released on January 25, 1993.
Caveats
A dual homing standby link may go active incorrectly.
FIP Microcode Version 1.1 was introduced on April 26, 1993.
Modifications
FIP 1.1 fixes the dual homing problem in Version 1.0.
Caveats
- The FIP transmitter will sometimes stop unexpectedly.
- The dual homing standby link confidence test (LCT) is too short.
- During physical connection management (PCM), the link error monitor (LEM) count is running.
- Phy-A can get traced when it is in WRAP-B mode.
FIP Microcode Version 1.2 was introduced on November 8, 1993.
Under certain conditions, users will experience a relatively large number of transitions and the transmitter will stop transmitting (transmitter hung). In this case, the downstream neighbor will lose the upstream neighbor.
Modifications
FIP 1.2 fixes all the caveats in Version 1.1.
FIP Microcode Version 1.3 was introduced on January 17, 1993. This version contains no changes in functionality. It was modified to support bundling only.
Version 1.4 was released on on March 4, 1994.
Modifications
This release fixes the problem that, under certain conditions, users experienced a relatively large number of transitions, and the transmitter would stop transmitting. In this case, the downstream neighbor would lose its upstream neighbor.
Version 10.0 was released on May 31, 1994.
Modifications
Version 10.0 supports the improved buffering scheme.
Version 10.0 was released on August 22, 1994.
Modifications
Version 10.1 fixes the following problems:
- Under heavy load, the FIP output may have hung.
- The FIP would not allow a connection topology of router Phy B to Phy A, and router Phy A to Phy B. [CSCdi21521]
Version 10.2 was released on January 30, 1995.
Modification
Before Version 10.2, under certain conditions, the FDDI would unnecessarily enter TRACE mode. Version 10.2 solves the problem.
Version 1.0 is the first officially released version of FSIP microcode. It was released on September 27, 1993.
Dependencies
The FSIP requires both SP Microcode Version 1.4 and Software Release 9.17(5) for operation.
FSIP Microcode Version 1.1 was introduced on January 17, 1994.
Modification
This version of the microcode fixes a bug that occurred when the FSIP received extremely short frames (shorter than the configured CRC). The following error message would be displayed:
%SYS-2-GETBUG: Bad getbuffer, bytes= 65535
-Process= "*Sched*", ipl= 3
-Traceback= 6772 8DA5C 188A 2040 104C 10000542 10008E0C 100001AE
This happened only in rare circumstances; most often if the physical connection was bad.
Version 10.2 was released on June 27, 1994.
Modifications
Version 10.2 supports the improved buffering scheme and the G.703 port adapter. It also contains some additional capability of buffering packets on the board itself.
Version 10.3 was released on August 22, 1994.
Modifications
Version 10.3 fixes the problem that the fast switching of SAP-encapsulated packets to Frame Relay-encapsulated serial lines sometimes failed.
Version 10.5 was released.
Modifications
Version 10.5 fixes the following problems:
- The FSIP would not communicate with certain older equipment that used Mark as the idle code. FSIP now supports a choice of either Mark or Flags as idle code.
- Version 10.5 adds support for txqlength to the FSIP. The field appears on the show interface output for the FSIP.
Version 10.6 was released.
Modification
Version 10.6 fixes the following problem:
- When cabled as a DTE, the FSIP with the default port adaptor (PA-7KF-SPA) will not go into loopback.
Version 1.0 is the first officially released version of HIP microcode. It was released with the introduction of the HSSI Interface Processor (HIP) on April 26, 1993.
Dependencies
The HIP requires System Software Release 9.17(3) or later, and SP Microcode Version 1.2 or later.
HIP Microcode Version 1.1 was introduced on January 17, 1994.
Modification
This version of the microcode has been modified to support future upgrades.
HIP Microcode Version 1.2 was introduced on May 2, 1994.
Modification
In prior versions of the microcode, transmitter delay did not work as expected. This has been fixed.
Version 10.0 was released on May 31, 1994.
Modification
Version 10.0 supports the improved buffering scheme.
Caveat
In CRC-32 mode, MTU and MTU - 1 frame sizes are treated as Giants.
Version 10.1 was released on December 20, 1994.
Modification
In CRC-32 mode, MTU and MTU - 1 frame sizes were treated as Giants. This has been fixed in Version 10.1.
Version 1.0 is the first officially released version of SIP microcode. It was released on January 25, 1993.
SIP Microcode Version 1.1 was introduced on June 21, 1993.
Modifications
SIP Microcode Version 1.1 indicates any changes in a serial interface line's state if the keepalives are turned on. It takes approximately 20 to 30 seconds to display the line state's change in the output produced by the show interface serial command.
Dependencies
SIP Microcode Version 1.1 requires System Software Release 9.17(4) or later.
SIP Microcode Version 1.2 was released on May 31, 1994.
Modifications
Version 1.2 supports fast switching of VINES.
Note SP Microcode Versions 1.1 and 1.3 were never released.
Version 1.0 is the first officially released version of SP microcode. It was released on January 25, 1993.
Caveat
In some environments intermittent bus errors may occur.
SP Microcode Version 1.2 was introduced with System Software Release 9.17(3) on April 14, 1993.
Modification
SP Version 1.2 fixes the problem with intermittent bus errors that could occur with Version 1.0.
SP Microcode Version 1.4 was introduced on September 20, 1993.
Modification
SP Version 1.4 provides support for the new Fast Serial Interface Processor (FSIP). The FSIP requires both SP Microcode Version 1.4 and Software Release 9.17(5) for operation.
 | Caution SP Microcode Version 1.4 must reside in ROM; it cannot be loaded from Flash memory. During the boot process, the system accesses the SP microcode. If the SP microcode ROM contains a version earlier than 1.4 and the router contains an FSIP, the system may fail to boot properly. |
SP Microcode Version 1.5 was introduced on January 17, 1994.
Modification
When source-route bridging is autonomously switched, occasionally the Token Ring will hang with the message "Output hung 800E."
SP Microcode Version 10.3 was released on June 22, 1994.
Modifications
Version 10.3 supports the improved buffering scheme.
SP Microcode Version 10.4 was released on August 22, 1994.
Modification
Version 10.4 fixes a bug that prevented fast switching of CLNS packets received from an Ethernet interface.
SP Microcode Version 10.5 was released.
Modification
Version 10.5 fixes a bug in all prior versions of SP microcode that made IPX autonomous switching vulnerable to Multibus Timeouts.
SP Microcode Version 10.6 was not released.
Caveat
On a Cisco 7000, IP packets that are received on ATM or HSSI interfaces will not have their TTL decremented if they contain options.
SP Microcode Version 10.7 was released.
Modification
Version 10.7 fixes the following problem. On a Cisco 7000, IP packets that are received on ATM or HSSI interfaces will not have their TTL decremented if they contain options.
Version 1.0 is the first officially released version of TRIP microcode. It was released on January 25, 1993.
Caveats
- Under very heavy loads on multiple interfaces, an interface may stop transmitting and receiving packets, and the TRIP may stop functioning.
- The interface may incorrectly report that the ring is beaconing.
- Occasionally an interface may fail to insert into the ring because it incorrectly assumes that the ring is beaconing.
- During Token Ring Lobe Test, an Adapter Check Error (0008 0003 0A5E 4F11) may occur.
TRIP Microcode Version 1.1 was introduced on August 9, 1993.
This release fixes all the caveats in the previous release.
TRIP Microcode Version 1.1 requires System Software Release 9.17(5) or later.
TRIP Microcode Version 1.2 was introduced on May 2, 1994.
- Configuring multiring caused RTMP problems. This has been fixed.
- Sometimes get transmit output hung. This has been fixed.
Version 10.0 was released on May 31, 1994.
Modification
Version 10.0 supports the improved buffering scheme.
Version 10.1 was released on August 22, 1994.
Modifications
Version 10.1 fixes the following problems:
- Some catastrophic errors would cause a flood of error messages. The number of messages has been reduced.
- This version significantly reduces the load on a queue which at overflow causes the interface to be placed in a reset state (CTRUCHECK).
- The processing of some extremely rare events in noisy networks caused the card to cease operation.
- Token Ring interfaces kept too many buffers locally (very low receive queue limits) if SRB was enabled.
Customer Information Online
Customer Information Online (CIO) provides online information and electronic services to Cisco customers and business partners. Basic CIO services include general Cisco information, product announcements, brochures, descriptions of service offerings, and download access to public and authorized files. Customers with maintenance contracts receive a much broader offering, including technical tips, software updates, the Bug Navigator, configuration notes, release notes, and e-mail access to Cisco Technical Assistance Centers.
CIO 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 CIO (called "CIO Classic") supports Zmodem, Kermit, Xmodem, FTP, Internet e-mail, and fax download options, and is excellent for quick access to information over lower bandwidths. The WWW version of CIO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.
To access CIO:
- WWW--
http://www.cisco.com.
- Telnet--
cio.cisco.com (198.92.32.130).
- Modem--From North America, 408 526-8070; from Europe 33 1 64 46 40 82.
Use the following terminal settings: VT100 emulation; data bits: 8; parity: none; stop bits: 1; and baud rates up to 14.4 kbps.
Maintenance customers and partners can self-register to obtain full access. For a copy of CIO's Frequently Asked Questions, send e-mail to cio-help@cisco.com.
The complete caveats against this release are available on UniverCD, which is Cisco Systems' library of product information on CD-ROM. On UniverCD, access the System Software Release 9.17 Caveats in the "System Software Release 9.1" database.
