This release note describes the features, modifications, and caveats for Software Release 8.3, including 8.3(1) through 8.3(9). Refer to the Router Products and Configuration Reference publication, dated October 1991, for complete router product documentation for Release 8.3. A list and description of the current software versions available from Cisco Systems is included in the "Software Version Levels" section in this document.
Note Release 8.3(9) is the last maintenance Release for 8.3. Maintenance customers will continue to receive phone support from CE, but fixes will be made only to Release 9.0 and higher releases. As of August 2, 1993, Release 9.1(5) is the preferred upgrade path for a Release 8.3 user.
Note This release note no longer contains the microcode release notes. Information about system cards and microcode versions is contained in the Cisco publication
Microcode Release Note, part number 78-1069.
This release note covers the following topics:
- Software version levels, page 3
- New hardware features, page 4
- New software features for Release 8.3(1), page 4
- New software features for Release 8.3(2), page 12
- New software features for Release 8.3(5), page 13
- Additional user notes, page 14
- 8.3(9) caveats, page 17
- 8.3(8) caveats/8.3(9) modifications, page 23
- 8.3(7) caveats/8.3(8) modifications, page 24
- 8.3(6) caveats/8.3(7) modifications, page 27
- 8.3(5) caveats/8.3(6) modifications, page 33
- 8.3(4) caveats/8.3(5) modifications, page 42
- 8.3(3) caveats/8.3(4) modifications, page 43
- 8.3(2) caveats/8.3(3) modifications, page 51
- 8.3(1) caveats/8.3(2) modifications, page 57
- Customer information online, page 65
The table that follows describes the software versions for Cisco router and TRouter software. Refer to these descriptions when ordering software updates for Software Release 8.3.
Versions
| System
| Description
| ROMs
|
|---|
| 8.3(1-9)
| GS3
| CSC/3 Gateway Server Sets:
GS3-F
GS3-BF
GS3-FX
GS3-BFX
|
8
8
8
8
|
| 8.3(1-9)
| GS2
| CSC/2 Gateway Server Sets:
GS2-R
GS2-BR
GS2-RX
GS2-BRX
|
8
8
8
8
|
| 8.3(1-9)
| TR3
| CSC/3 TRouter Sets:
TR3-X
|
4
|
| 8.3(1-9)
| TR2
| CSC/2 TRouter Sets:
TR2-RX
|
8
|
| 8.3(1-9)
| IGS
| IGS Server Sets:
IGS-R
IGS-BR
IGS-RX
IGS-BPRX
IGS-BRX
|
8
8
8
8
8
|
Letter Key:
B--Bridging software
F--Standard system software with ciscoBus complex
P--Protocol translation software
R--Standard system software which executes out of ROM
X--Standard and Commercial/DDN X.25 software
|
The software images that run on a CSC/2 processor have been expanding as new feature code has been added for each software release. Some of these images (GS2-R, GS2-BR, GS2-RX, GS2-BRX, TR2-RX) have now exceeded the 1-MB ROM capacity of the current CSC/2 processor boards. As a result, as of Software Release 8.3 these images are shipped on 2-MB ROMs. This change requires an accompanying PAL change to support the addressing of the added megabyte. The new PAL (Cisco Part Number 17-0987-01) that Cisco provides for this support is compatible only with 2-MB ROMs and does not support the use of 1-MB ROMs.
Refer to the Cisco Systems publication Modular Products Hardware Installation and Reference for the procedures for updating your system with the latest software version, including procedures for EPROM replacement.
Release 8.3 introduces support for the High-Speed Serial-Port Communications Interface (HSCI) complex, which provides a connection for two new interfaces: HSA and ULA. HSA provides connection for the High-Speed Serial Interface (HSSI) specification, and ULA provides connection to UltraNet network environments.
The HSA interface provides a single, full-duplex synchronous serial connection capable of transmitting and receiving data at up to 52 Mbps. The HSSI specification is a de facto industry standard, providing connectivity to DS3, E3, Frame Relay at DS3, and other high-speed wide-area services through a DSU or line termination unit.
The ULA interface product, which is available exclusively from Ultra Network Technologies, provides a fiber or coax interface to supercomputer environments through an Ultra Network Technologies hub at rates of up to 125 Mbps.
Note Use of these devices requires installation of new microcode levels. Refer to the Cisco publication
Microcode Release Note, part number 78-1069, for information about the mandatory upgrades required for these new Release 8.3 features.
This section describes the major functions introduced in Release 8.3(1) of the router software.
Release 8.3(1) includes the following enhancements and changes to its interface configuration capabilities.
- Support has been added for the following new UltraNet interface command, as listed on page 6-43 of the Router Products Configuration and Reference publication:
ultranet address ultranet-mac-address
- Support has been added for the new HSSI interface command, as described on page 7-13 of the Router Products Configuration and Reference publication. Enhancements to the loopback command now allow testing of Cisco's UltraNet hardware, testing of the HSSI interface at the applique, the DTE side of the DSU, the line side of the DSU, and the remote DSU. The format of this command follows:
[no] loopback {applique|dte|line|remote}
- Several changes have been made to the setup facility, including the addition of new prompts to allow users to leave the System Configuration Dialog and to configure the DEC MOP server feature. Several minor modifications have also been made to the onscreen prompts within the configuration command script.
- The following service commands have changed format for Release 8.3:
Old Format New Format
service domain ip domain-lookup
service ipname ip ipname-lookup
service subnet-zero ip subnet-zero
Note The old formats for the service commands are accepted in configuration input, but the output of the
write terminal or
show config commands displays the new forms.
- The tcp-keepalives {in|out} keyword has been added to the list of service commands.
- Extensions have been added to the banner command to display a message-of-the-day banner and a banner upon opening an EXEC process or an incoming message.
- Addition of the [no] exec-banner line command allows users to enable or disable banner commands.
- Support for configurable buffer sizes has been added through the new buffers global command, as listed on page 4-4 of the Router Products Configuration and Reference publication.
- A new description interface subcommand has been implemented to add a description of an interface to a configuration file.
- Additional flags have been added to the transmitter-delay command to allow configuration for the IGS router and the new HSSI hardware.
- The priority-list list interface configuration command sets up priority queuing on a specified interface. Optional keywords for this command allow fine-tuning of the packet count and enable traffic priority to be assigned by access list and Ethernet type code access list number, as well as by origin or destination to FTP or UDP ports.
- The error-threshold command now provides a means to configure the frequency at which the error recount will be set as listed on page 7-11 of the Router Products Configuration and Reference publication.
- The mtu command has been added to allow adjustment of the default maximum packet size.
Software Release 8.3(1) includes enhancements to Cisco's routing configuration capabilities. These modifications are described in the Router Products Configuration and Reference publications.
The following enhancements have been made to Cisco's IP routing implementation:
- IP autonomous switching support has been added to provide faster packet processing for AGS+ systems by allowing the ciscoBus complex to switch packets independently, without interrupting the system processor.
- The new command follows:
[no] ip route-cache [cbus]
Note Customers who want to use autonomous switching must upgrade the microcode on their MEC, FDDI, and CCTL cards. (The Cisco publication
Microcode Release Note, part number 78-1069, provides more information about this.) Because a significant number of components needs to be replaced on these boards, we recommend that users take advantage of Cisco's advance board replacement service to implement these upgrades. For more details on this service, contact Customer Service at 800-553-NETS (6387).
- For ICMP echo requests, support has been added to set the DF ("Don't Fragment") bit in the IP header and to report ICMP unreachables with code equal to "Fragmentation needed but DF set." For information on these capabilities, refer to the "IP Ping Command" section of the Router Products Configuration and Reference publication.
- IP header compression support has been implemented in accordance with RFC 1144. This feature allows compression of TCP/IP packets along HDLC serial links, and can be executed with the following command:
[no] ip tcp header-compression [passive]
- Support has been added for multiple IP helper addresses per interface, executed through the command ip helper command address address.
- IP Path MTU Discovery (associated with the ip mtu command, as documented on page 13-18 of the Router Products Configuration and Reference publication) has been added to allow dynamic discovery of the maximum transmission unit of an internet path, according to RFC 1191.
- Support has been added for HP Probe Proxy to allow a route to respond to HP Probe Proxy Name requests. Users can enable this feature through the interface configuration subcommand:
ip probe proxy
- EGP route time-out periods have been modified to occur in the correct intervals.
Cisco's AppleTalk protocol implementation has undergone the following modifications:
- Changes have been made to the command syntax to replace references to Phase 1 and Phase 2 with the corresponding references: nonextended (for Phase 1) and extended (for Phase 2). These changes are documented throughout the Router Products Configuration and Reference publication.
- The following global configuration commands have been added:
[no] apple strict-rtmp
[no] apple send-rtmp
[no] apple proxy-nbp
appletalk iptalk-baseport
- appletalk timers (documented on page 10-15 of the Router Products Configuration and Reference publication)
- The following interface subcommands have been added:
- appletalk iptalk (documented on page 10-13 of the (Router Products Configuration and Reference publication)
[no] apple distribute-list {in | out}
- appletalk discovery (documented on page 10-13 of the Router Products Configuration and Reference publication)
- The following clear commands have been added:
clear apple neighbors
clear apple route
Release 8.3(1) includes the following modifications to Cisco's ISO CLNS protocol implementation:
- The maximum number of ISO IGRP routing processes has been increased to ten. (Previously, the limit was six.)
- Interfaces that are running ISO IGRP can now be restricted to sending routing updates for level 2 only. This feature can be defined through the following command.
clns router igrp tag level2
- Cisco's Apollo protocol implementation now supports access lists that can be referenced by name through use of the command apollo access-list.
Release 8.3(1) includes the following changes to Cisco's Banyan VINES protocol implementation:
- The vines serverless command has been added to allow configuration of a network without a server.
There are several new additions to Cisco's support for IBM connectivity environments with Release 8.3(1). (For information on source-route bridging, refer to the "Bridging" part of the reference manual.)
Software Release 8.3(1) introduces support for serial tunnel (STUN) functionality, also known as SDLC Transport, for encapsulating SDLC-framed traffic into IP packets and routing them over any IP-supported media through use of the TCP transport mechanism.
- Support is offered for the following STUN global commands:
[no] stun peer-name ip-address
[no] stun poll-interval milliseconds
[no] stun primary-pass-through seconds
[no] stun protocol-group group-number protocol
[no] stun schema name offset constant-offset length address-length
format format-keyword
- Support is offered for the following STUN interface subcommands:
encapsulation stun
[no] stun group group-number
[no] stun proxy-poll address address modulus modulus {primary|secondary}
[no] stun proxy-poll address address discovery
[no] stun route all tcp ip-address
[no] stun route all interface serial interface-number
[no] stun route all interface serial interface-number direct
[no] stun route address address-number tcp ip-address
[no] stun route address address-number interface serial interface-number
[no] stun route address address-number interface serial interface-number direct
- Support for NetBIOS Access Filters has been added to control packets transmitted across a Token Ring bridge using the NetBIOS interface. Cisco has implemented two types of filters: one for source and destination station names and one for arbitrary byte patterns in the packet itself. The new commands follow.
[no] netbios access-list host name {permit|deny} pattern
[no] netbios input-access-filter-host name
[no] netbios output-access-filter-host name
[no] netbios access-list bytes name {permit|deny} offset pattern
[no] netbios input-access-filter bytes name
[no] netbios output-access-filter-bytes name
With Software Release 8.3(1), Cisco introduces new and enhanced support for WANs.
- Frame Relay is now supported as an encapsulation for the routing of IP, DECnet, AppleTalk, XNS, Novell, VINES, and ISO CLNS protocols, and for transparent bridging through use of the command frame relay map. SDLC Transport (also known as serial tunnel, or STUN) and source-route bridging (SRB) are also supported over Frame Relay by virtue of their encapsulation within TCP/IP.
- Dial backup functionality has been added to provide protection against WAN downtime by allowing configuration of a backup serial line via a circuit-switched connection. Support has been added for the following dial backup commands:
[no] backup delay {enable-delay|ever} {disable-delay |never}
[no] backup interface interface-name
[no] backup load {enable-threshold|never} {disable-load|never}
- Support is provided for Switched Multimegabit Data Service (SMDS), a packet-switched WAN service provided by the Regional Bell Operating Companies (RBOCs) and other telephone service carriers. Cisco provides an SMDS interface at T1 rates. The following SMDS interface subcommands, as listed on page 8-53 of the Router Products Configuration and Reference publication, have been added:
encapsulation smds
[no] smds address smds-address
[no] smds att-mode
[no] smds enable-arp
[no] smds multicast protocol-type smds-group-address
[no] smds static-map protocol-type protocol-address smds-address
Cisco's SNMP support has undergone several changes.
- Support has been added for SNMP MIB II (RFC 1157).
- The global configuration command snmp-server system-shutdown has been added.
- A new clear counters EXEC command has been added to clear interface counters.
Cisco has added new bridging support with Release 8.3(1), including enhancements to transparent bridging and source-route bridging (SRB).
Release 8.3(1) includes the following changes to Cisco's software support for transparent bridging:
- For the IEEE spanning tree, multiple spanning-tree domains are now supported. Domains are given a value from 1 to 10 and are specified with the following command:
bridge group domain domain-number
- Support has been added to filter LAT frames to allow the selective inclusion or exclusion of LAT multicast service announcements on a per-interface basis. The new commands follow.
- Global:
bridge group lat-service-filtering
- Interface:
bridge-group number input-lat-service-deny grouplist
bridge-group number input-lat-service-permit grouplist
bridge-group number output-lat-service-deny grouplist
bridge-group number output-lat-service-permit grouplist
- The show span command has been enhanced to display LAT group code filtering.
- Transparent bridging software has been modified to allow bridging of packets in X.25 frames. The x25 map command has been modified to allow this capability.
- Transparent bridging software now supports bridging of packets over Frame Relay networks. This feature works on networks that support a multicast facility as well as those that do not support multicasts.The frame-relay map interface subcommand has been modified to allow this capability.
Following is a list of the Release 8.3(1) changes to Cisco's source-route bridging software.
- The multiring command has been extended to enable collection and use of routing information fields (RIFs) for all protocols. The software now allows per-protocol specification on a given interface to use multiring protocols. The protocols supported within this feature are Apollo Domain, AppleTalk, ISO CLNS, DECnet, IP, Novell IPX, Banyan VINES, and XNS.
- A new command has been added to limit the size of the backup queue for remote source-route bridging. This command controls the number of packets that can wait for transmission to a remote ring without being discarded.
[no] source-bridge tcp-queue-max number
- The show source-bridge EXEC command now displays the queue length.
- The command source-bridge remote-peer now has the optional keyword, lf size, which allows the maximum-size frame to be sent to the remote peer to be specified.
As of Software Release 8.3(1), Cisco's documentation set has a new format that includes the following changes:
- A comprehensive error message appendix has been added that includes error messages for all Cisco products.
- Manuals have been reorganized to support specific tasks. Each new software manual provides sections on using the setup command facility, using the system, configuring the system, system management, and protocol-specific configuration. The new manuals also provide summaries of relevant commands with each chapter.
This section lists the commands and capabilities of the Cisco router software that are no longer supported as of Release 8.3(1).
- Cisco's support for the Banyan VINES protocol no longer includes the vines propagate command.
- Cisco's support for the AppleTalk protocol no longer includes the show apple detailed command.
- Cisco's support for the AppleTalk protocol no longer includes the show apple lock command.
- Cisco's support for Frame Relay no longer includes the frame-relay dlci-bits command.
- Cisco's support for SNMP no longer includes X.25 virtual circuits clear traps.
- The show priority command is no longer supported in Release 8.3.
This section describes new software features and enhancements that were added to the software with Release 8.3(2).
With Software Release 8.3(2), the software no longer allows the enable password or the console password to be used as the community string for SNMP.
Software Release 8.3(2) includes enhancements to Cisco's routing configuration capabilities. These modifications are described in the Router Products Configuration and Reference publication.
Enhancements have been made to Cisco's IP routing implementation.
- Cisco has changed the defaults for commands that configure address resolution using proxy ARP and probe ARP. The defaults in Release 8.3(2) are as follows:
ip proxy arp
no arp probe
- Cisco has improved support for HP Probe Proxy, first introduced in Release 8.3(1), to allow a route to respond to HP Probe Proxy Name requests. Users enable this feature through the interface configuration subcommand:
ip probe proxy
Because the defaults are now the no arp probe and no ip proxy arp commands, you must specifically configure the arp probe command on all interfaces that support HP Probe Proxy. Other changes include the following:
- Unsolicited probe replies are now cached. This improves user response time when starting sessions and helps eliminate unnecessary probe VNA exchanges.
- ARP probe is now supported over both Ethernet and IEEE encapsulation. Ethernet encapsulation is used whenever possible.
- DTC probe still needs to be bridged. The router notices the difference between DTC probes and other probes and will not answer DTC probes.
- The only limitation to the proxy table is the amount of memory in the router and the amount of NVRAM, if the proxy table is stored there. Alternatively, the proxy table can be netbooted after the router reloads.
This section describes new software features and enhancements that were added to the software with Release 8.3(5).
Software Release 8.3(5) adds the ability to perform remote source-route bridging over X.25 on the IGS/TR platform.
The operational ring speed for the ISG Token Ring connector is set with the following configuration command:
ring-speed speed
The argument speed is 4 for 4 Mbps, or 16 for 16 Mbps.
This section provides technical notes that supplement information found in the software and hardware manuals.
If the system receives an indication of a cabling problem from a CSC-R16 Token Ring interface, that interface is placed in a reset state. The system does not attempt to restart the interface. To restart the interface, correct the cabling problem and use the clear interface command to reset it.
The system functions in this manner because periodic attempts to restart the Token Ring interface have drastic effects on the stability of routing tables, and sometimes on the stability of Token Ring networks themselves.
Netbooting over X.25 or Frame Relay is not allowed to a broadcast address. You must specify the address of a server host to successfully netboot the system files. Use an off-net map entry of the destination. This means that you cannot simply have an X.25 or Frame Relay map entry for the next hop router. You need a map entry (use the x25 map or frame-relay map commands) for the host from which you will boot, even if that host is not on a directly connected network.
X.25 Example
The x25 map command is used to map an IP address into an X.121 address. There must be an x25 map command which matches the IP address given on the boot system command line. In order to netboot over X.25, the address of the system from which to netboot must be given explicitly, and an x25 map entry must exist for that site, as the following example illustrates.
boot system gs3-bfx.83-2.0 131.108.13.111
!
interface Serial 1
ip address 131.108.126.200 255.255.255.0
encapsulation X25-DCE
x25 address 10004
x25 map IP 131.108.13.111 10002 BROADCAST
lapb n1 12040
clockrate 56000
Frame Relay Example
If file gs3-bfx is to be booted from a host with IP address 131.108.126.2, the following would need to be in the configuration:
boot system gs3-bfx 131.108.126.2
!
interface Serial 0
encapsulation frame-relay
frame-relay map IP 131.108.126.2 100 broadcast
Routers running software version 8.3(1) cannot interoperate over SMDS with routers running version 8.3(2) or later.
In order to configure load sharing across multiple X.25 serial lines, the entries for all the adjacent interface IP addresses need to be included in the x25 map command for each serial interface.
As an example, two routers, Cisco A and Cisco B, each with two serial interfaces, would require the following configuration files to allow subnetting the same IP address:
--------- ---------
| |------/-----------| |
| | S1 S0 | |
| Cisco | | Cisco |
| A |------/-----------| B |
| | S2 S3 | |
--------- ---------
Cisco A
interface serial 1
ip 131.108.170.1 255.255.255.0
x25 address 11
x25 map ip 131.108.170.3 13
x25 map ip 131.108.170.4 13
interface serial 2
ip 131.108.170.2 255.255.255.0
x25 address 12
x25 map ip 131.108.170.4 14
x25 map ip 131.108.170.3 14
Cisco B
interface serial 0
ip 131.108.170.3 255.255.255.0
x25 address 13
x25 map ip 131.108.170.1 11
x25 map ip 131.108.170.2 11
interface serial 3
ip 131.108.170.4 255.255.255.0
x25 address 14
x25 map ip 131.108.170.2 12
x25 map ip 131.108.170.1 12
There is an interaction between AppleTalk and FDDI when mixing system version 8.2(4) (only) and later versions. If a router has both MCI Ethernet and FDDI interfaces while running 8.2(4), runts may be generated by the MCI interfaces when packets are sent from a router running a version later than 8.2(4) across the FDDI to the 8.2(4) router and forwarded via the MCI Ethernet interface(s).
The solution is to upgrade all 8.2(4) routers with FDDI and MCI Ethernet interfaces before upgrading any other routers on the FDDI ring in question. A workaround is to disable AppleTalk fast switching on the MCI Ethernet interfaces of the affected 8.2(4) routers. This is done with the command no apple route-cache.
With Release 8.3(2), Cisco's Novell IPX implementation supports packet sizes of more than 576 bytes on media that are capable of carrying packets of that size. Until recently, no Novell end node would send or accept a packet larger than this size; this has changed in newer Novell software. The software now accepts Novell IPX packets up to the maximum size allowed on the media. [CSCdi04193]
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.
On page 19-7 in the section "Configuring Ungermann-Bass Net/One XNS," it states that netbooting does not work in the current Cisco software. However, there is a workaround for this restriction. Because Ungermann-Bass devices can boot from another protocol that cannot be routed, you can use bridging to pick up the network identifier (ID). The steps for this workaround follow:
Step 1: In order for the NIU to netboot correctly across a Cisco router, you need to bridge 0x7000 (etype 7000) to 0x7005 inclusively.
Step 2: The download server (DLS) on the NetDirector has to run with the -Bytes option on. This option causes the NIUs to receive their XNS network ID as it is configured in their LC file. The default startup for a download server causes an NIU to use the same XNS network ID as the download server.
Step 3: To locate service names not on the same segment, the users must type *service_name instead of just service_name, so that the NIU will do an all-xns-net-broadcast instead of just a local-xns-net broadcast (XNS type 4 destined to -1.ffff.ffff.ffff).
This section describes possibly unexpected behavior by Release 8.3(9). Unless otherwise noted, these caveats apply to all 8.3 releases up to and including 8.3(9).
- The conversion of special characters to uppercase for use in zone name comparisons is incorrect. This may result in incorrect responses to ZIP queries for zone names containing such characters. The workaround is to use only alphanumeric characters in zone names. [CSCdi02637]
- It is possible for the 802.2 length field to be set incorrectly on AppleTalk packets fast-switched from Ethernet/802.3 media to FDDI media. [CSCdi02653]
- If AppleTalk routing is configured for nondiscovery mode on a Token Ring interface connected to a network whose zone-name configuration does not match that of the router, the interface will still be used for AppleTalk routing. The correct behavior would be to shut down AppleTalk routing on the interface in question until the configuration problems had been resolved. [CSCdi03451]
- Interfaces connected to end-nodes using AppleTalk for VMS prior to version 3.01 should have the AppleTalk fast switching cache disabled to ensure that all packets will be accepted by those end-nodes. [CSCdi04696]
- On extended AppleTalk networks with multiple defined zone names, some devices may appear in more than one zone when viewed from a Macintosh that lies across the router; for example, MktgLaser appears in ZoneA and ZoneB, although it is defined to reside in ZoneA only. This is known to occur with Apple LaserWriter IIg's and pre-1.5 version Dayna EtherPrints. [CSCdi04951]
- In large AppleTalk internets, an 8.3 router which is missing a zone name may experience unusually high CPU utilization as displayed by show process. The process AT MAINT will take an increasingly larger interval each time it runs (as shown in the "usecs" column of the show process display). The workaround is to correct the missing zone condition. This problem is corrected in release 9.0. [CSCdi09487]
- AppleTalk packets cannot be routed from X.25 interfaces directly onto either FDDI or Token Ring interfaces. This capability is provided in all router software releases above and including 9.0. [CSCdi09630]
- The command show apple adjacent-routes in the online help list for show apple should really read as show apple adjacent. [CSCdi10469]
- When an interface is configured for nonextended AppleTalk, it will unexpectedly try to bring itself up after an AppleTalk address is assigned but before a zone is specified. This leads to improper port startup. This can be avoided by specifying the zone first and the AppleTalk address second. [CSCdi11516]
- It is possible for system reloads to occur when the nonvolatile configuration memory is manipulated from more than one terminal session. Only one terminal at a time should do commands from the set {show config, write memory (or write with no argument), write erase, config from memory}. [CSCdi03856]
- Changing IGS serial interface MTU values, or enabling the SMDS encapsulation on IGS serial interfaces, may result in miscalculation of the new buffer quotas. This damage manifests itself as the appearance of incorrect or negative values for buffer quotas in the show buffers display. This may be worked around by explicitly configuring buffer management parameters using the buffers command. [CSCdi04062]
- If a router gets its NVRAM erased or corrupted, and a reload occurs, an administrator must be present to reconfigure the box. Instead, it would be good to turn on service-config automatically in such a circumstance so that the box can restart on its own. [CSCdi07521]
- If the system is started with an HSSI interface configured for SMDS, and the encapsulation for that interface is later changed to HDLC, the interface MTU value is not reset, even though the ciscoBus buffers are reapportioned as though the MTU had been reduced to 1500. The workaround is to manually reduce the interface MTU to 1500. [CSCdi01406]
- If a router is receiving routing updates (for any protocol) over a Frame Relay multicast DLCI, it will learn routes via the Frame Relay interface, even if the individual data DLCIs associated with remote hosts or routers are defunct. This can result in failure to route around some Frame Relay failures. [CSCdi02499]
- The no ip broadcast-address command should return to default. There is no further information available concerning this problem. [CSCdi07563]
- If a very large FDDI SMT frame is received or sent by the router and debug fddi-smt is configured, the debug output for that frame may be corrupt. [CSCdi09114]
- If the IP MTU is set to less than the interface MTU, packets will be process-switched, rather than fast-switched. [CSCdi09453]
- IP accounting is not supported for UltraNet interfaces. Incorrect data is entered into the accounting table. The fix is to disable IP accounting on UltraNet interfaces. [CSCdi10595]
- The value in "Counters last cleared" field sometimes shows as "*****" after an extended period of time. The same field also sometimes remains stuck at 0:00:00. [CSCdi11305]
- 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's 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]
- The show traffic command will display certain fields as negative numbers once the values wrap into the sign bit. [CSCdi06979]
- While routing IP, if two ARP-style interfaces have the same IP address and one of those interfaces is shut down, the wrong MAC address could get entered into the ARP table. The workaround is to remove the duplicate IP address from the shutdown interface with the no ip address interface subcommand. [CSCdi07036]
- In some netbooting configurations, a client may have multiple interfaces that it could use to traffic data back and forth to the server while it is netbooting. The first thing a client will do if the server is not on the same physical wire as one of its interfaces is broadcast a request for a proxy ARP to get to the server. This is asking a neighbor to help him traffic to the server. Once a neighbor responds, data will be forwarded to the server. In some cases, a second neighbor might step and tell the client it will act as the proxy ARP. When this happens, the client gets confused as its original path to the server has now changed. It is more common that two or more parallel IEEE media between the client and its only neighbor will also cause this to happen. This will most likely cause an error similar to the following: [CSCdi07727]
Booting gs3-k.91 from 223.255.254.254: !O.OO.O.......... [timed out]
- A race condition in the show ip cache command can cause the router to reload. This caveat cannot be completely fixed in 8.2 and 8.3. [CSCdi07900]
- The system can refuse to allow the user to remove static ARP entries which were specified by the user, with the error message "Can't unset interface address." The system is wrongly confusing the user supplied ARP entry with the system generated ARP entries for its local network interfaces. The correct behavior is to allow the user to remove any ARP entries they added to the ARP table. This can happen when the user explicitly specifies an ARP entry for the local IP address of an interface on which ARP is not running. [CSCdi08523]
- If an interface is configured with ip unnumbered and no ip split-horizon, no routing updates will be received on that interface. [CSCdi08717]
- Static routes that point to destinations reached via a route that has expired are not removed from the routing table. [CSCdi09564]
- If a route is known to a network or subnet and a secondary address is configured on a down interface, and the secondary address matches the network or subnet in the routing table, the route will be replaced. The result is a connected route to a down interface. [CSCdi09845]
- Whenever it appears in the IP routing table, network 0.0.0.0 is a candidate default route. This is not always reflected by the show ip route display. [CSCdi02203]
- When an IP IGRP update is created for a major network which is subnetted and directly connected to the router, but the update in question is being sent through an interface which does not lie in the network in question, the metric chosen for the major net may not be the best of the metrics to any of its subnets. Furthermore, if the connection to the major net in question is through a secondary address, the network will not be included in the IGRP update at all. [CSCdi02859]
- When a router is configured with two interfaces onto an IP network, if the first interface fails, EGP sessions will still use this address as the source address of their packets. This creates a "black hole" with a loss of connectivity. [CSCdi04549]
- BGP will accept a NEXT_HOP path attribute that is the router's own address. [CSCdi04961]
- An exceedingly rare race condition with IGRP can cause the router to reload. IGRP must simultaneously learn a new route while the routing table is being cleared. [CSCdi07276]
- Configuring RIP when there are no IP addresses in the router will cause the RIP router code to fail. The workaround is to remove and re-enter the RIP configuration after assigning an IP address. [CSCdi07765]
- If secondary addresses are used, in some circumstances IGRP can duplicate network routes in secondary advertisements. Normal operation is unimpaired, but excessive bandwidth is used. [CSCdi08511]
- When IP extended access lists are used, and the extended access list has not yet been defined, some usages result in all packets being denied. Other usages result in all packets being permitted. [CSCdi08718]
- If a neighbor command is used with IGRP, RIP, or HELLO, and the neighbor is not in the major net as the primary address of the outbound interface, the routing update will be sent with an incorrect source address. This can result in incorrect routing at the neighbor. [CSCdi08770]
- CLNS packets are not fast-switched correctly onto FDDI media. CLNS fast switching should be disabled on all FDDI interfaces. [CSCdi01839]
- Prefix route advertisements will count to infinity over networks when a prefix goes unreachable when doing ISO-IGRP interdomain routing over links where split horizon is not performed. This includes X.25, Frame Relay and SMDS networks. [CSCdi07379]
- ES-IS cache entries for a disabled interface are not flushed when the interface is disabled. This means that packets destined to systems that were formerly reachable through that interface may be lost until the cache entries time out (maximum of five minutes). [CSCdi08490]
- CLNS packets that are slow switched will always have their checksums calculated from scratch, even when the incoming packet has checksums turned off. This has no operational impact, other than slowing down packet forwarding and receipt if the original packet did not have checksums enabled. [CSCdi08567]
- If there are any CLNS discard routes configured, and they are redistributed into ISO-IGRP, they will not be advertised. The workaround is to configure a fictitious static route so it can be redistributed. [CSCdi09917]
- The router always chooses the last entry in the neighbors table when responding to a client request. The correct behavior is to respond with the first entry in the table. [CSCdi05000]
- When a switch is reconfigured to use a different DLCI to reach the same end address, the router doesn't flush the "deleted" map entry and attempt to learn a new mapping. [CSCdi03757]
- The router does not support X.25 clear request packets which have facilities or call user data attached. These packets are neither accepted on connections terminating at the router nor forwarded by the X.25 switching code. [CSCdi04048]
- The Frame Relay encapsulation code doesn't correctly check the status of a DLCI. The result is that packets can be sent on a DLCI which the Frame Relay switch has indicated as deleted via the LMI messages. This problem shows up if a router is misconfigured such that a mismatch exists between the router's DLCI and those defined in the Frame Relay switch. The workaround is to configure the router with the correct DLCIs. [CSCdi05481]
- The x25 pvc bridge number interface command is not properly stored in the router's configuration memory. [CSCdi06683]
- Under unusual circumstances, a RESET of a virtual circuit may not properly discard all in-transit data. This may cause an additional RESET of the VC to occur. [CSCdi07811]
- The Cisco X.25 implementation allows both modulo 8 and modulo 128 virtual circuits to coexist on the same interface; this is nonstandard. [CSCdi07812]
- Regarding the x25 map ip ipaddr broadcast command, all x25 map commands must accept an X.121 address for association with each protocol address mapped to. Rather than having the broadcast taken as an X.121 address incorrectly, the configuration will now contain an X.121 address before the broadcast keyword is specified. [CSCdi08630]
- The X.25 idle timer previously applied to SVCs which were switched (x25 route) or non-switched on an interface. Now only non-switched SVCs are subject to the X.25 idle timer. [CSCdi09927]
- Adjusting the Novell output-sap-delay to a large number, for instance 200 ms, may cause an increase in input queue drops. A workaround for this would be to use a smaller number for the delay, and/or increase the size of the input queue. Novell recommends a SAP interpacket delay of 55 ms. [CSCdi07338]
- If a Novell network number is assigned to an administratively shut down interface and the router has a valid alternative route to that same network in its routing table, then poison SAPs will be routed to that network. A result of this possibly unexpected behavior is that it will sometimes appear that the router is violating split-horizon and sending poison SAPs back out the interface they arrived on. Regular periodic SAP updates do not display this behavior. The workaround is to remove Novell network numbers from administratively shutdown interfaces. [CSCdi07425]
- A race condition in the show novell cache command can cause the router to reload. [CSCdi09163]
This section describes possibly unexpected behavior by Release 8.3(8). Unless otherwise noted, these caveats apply to all 8.3 releases up to and including 8.3(8). For additional caveats applicable to Release 8.3(9), see the caveats sections for newer 8.3 releases. The caveats for newer releases precede this section.
All the caveats listed in this section are resolved in Release 8.3(9).
- AppleTalk addresses of the form 0.X, where X is any valid node number, are erroneously entered into the fast-switching cache. This may possibly affect systems with more than one operational nonextended interface. [CSCdi10802]
- Zone names that begin with one or more leading blank spaces are not properly stored in the configuration memory. This may lead to zone conflicts when the system is rebooted; the parser will consume all leading white space when parsing the zone name. To prevent such a situation, zone names with leading blank spaces should not be used. The correct system behavior would be to store the first leading blank space as the sequence :20 using the special colon notation. [CSCdi11052]
- A ZIP GetMyZone reply is sent in response to a ZIP GetLocalZones request on nonextended interfaces. This is an unexpected response on Macintoshes running AppleTalk v58. The correct behavior is to respond with a GetLocalZones reply. [CSCdi11248]
- The parser sometimes claims that incomplete command names are not unique. [CSCdi10554]
- Upon receipt of IP directed broadcast packets, the system erroneously attempts to resolve the directed broadcast address via HP Probe address resolution broadcasts. This occurs if the directed broadcast is destined for a directly connected interface, and that interface is configured for arp probe. The system then also correctly forwards the directed broadcast as a data link layer broadcast (if not disabled via the configuration command no ip directed-broadcast). The system should be sending the directed broadcast as a (data link layer) broadcast out the directly connected interface, but should not be attempting to perform address resolution on the IP directed broadcast address. [CSCdi09627]
- The Cisco IPX ping command was limited to a maximum of 1500 bytes. This patch increases the ping maximum to 4096 bytes for segments which supports that size. [CSCdi10130]
This section describes possibly unexpected behavior by Release 8.3(7). Unless otherwise noted, these caveats apply to all 8.3 releases up to and including 8.3(7). For additional caveats applicable to Release 8.3(7), see the caveats sections for newer 8.3 releases. The caveats for newer releases precede this section.
All the caveats listed in this section are resolved in Release 8.3(8).
- Serial interfaces configured with discovery mode never become operational. This will be resolved in a future release. [CSCdi09532]
- 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 some conditions the show decnet route command may cause the router to reload. This has been fixed. [CSCdi07664]
- The parser sometimes claims that incomplete command names are not unique. [CSCdi10554]
- The problem was simply that 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 shutdown 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 it's unique address, which is a problem in the above scenario. [CSCdi07105]
- Due to interactions between the bridging code and driver code, the spanning-tree state would be handled incorrectly. 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 will see the port go into forwarding immediately. This can cause temporary network melt downs. [CSCdi09535]
- 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 that use this command to restrict access. [CSCdi09517]
- When initiating a TFTP read request, the system can generate TFTP packets with invalid UDP checksums. This only happens when the request is transmitted out an unnumbered interface. If the TFTP server has UDP checksumming enabled, TFTP read requests via the unnumbered interface will fail. Turning off UDP checksumming at the TFTP server, or restricting TFTP reads to numbered interfaces avoids this problem. [CSCdi09577]
- The 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]
- 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]
- 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 log in and log out at that client, and the affected user will be able to log in and change their password. [CSCdi09467]
- This patch fixes an interoperability issue between the Cisco Novell IPX routing fast switching implementation between Release 9.1 and 8.3 or 9.0 software releases before either 8.3(7.2) or 9.0(5.1). Note: 8.2 has the same problem as 8.3 and 9.0, but no fix will be generated for that release.
- In the 9.1 release, fast switching was enhanced to allow communication to FDDI and serial end hosts. Before 9.1, the router did not fast switch Novell frames to a Novell FDDI end host, but would always process switch them instead, so communication between actual end hosts was always effective.
- The older release Novell fast switching code wrote packets sent to next-hop remote routers on FDDI and serial links with extra padding bytes, in such a way that it guaranteed that Novell frames output on Ethernet interfaces by the remote router would always have at least 64 bytes of data (plus 4 bytes of checksum).
- The 9.1 fast switching code generates correctly formatted frames on FDDI and serial interfaces. However, the older releases of software will misinterpret these frames when fast switching, and generate output frames on Ethernet that, while valid frames, are smaller than 64 bytes.
- Some versions of PC Ethernet drivers seem to require a 64 byte minimum frame size (plus 4 bytes of checksum). As such, if they are in a setting where a 9.1 and previous release router are running in series, they will not be able to accept the smaller frames.
- This patch allows 8.3 and 9.0 to operate correctly with both correctly formatted input frames from release 9.1, or incorrectly formatted input frames from previous releases, on both FDDI or serial.
- Note 1: The problem in 8.3 and 9.0 can be worked around by turning off fast switching on the 9.1 router's FDDI or serial interface.
- Note 2: This patch will also fix problems where 8.3 or 9.0 cannot correctly forward frames sent by a PC FDDI end host onto an Ethernet. [CSCdi09754]
- Novell, XNS, and Apollo maximum-path 0 is accepted and displayed by the system but the default maximum-paths is 1. If a user types a maximum path of zero, make this return to the default setting of 1. [CSCdi09955]
- XNS RIP General Request replies have the split-horizon rule inadvertently applied to them, split-horizons should not be applied to XNS General Requests Responses. [CSCdi10294]
This section describes possibly unexpected behavior by Release 8.3(6). Unless otherwise noted, these caveats apply to all 8.3 releases up to and including 8.3(6). For additional caveats applicable to Release 8.3(8), see the caveats sections for newer 8.3 releases. The caveats for newer releases precede this section.
All the caveats listed in this section are resolved in Release 8.3(7).
- An error has been found in the AppleTalk fast switching functionality that results in invalid AppleTalk packets being generated. This happens when a packet is being received on a ciscoBus FDDI interface running extended AppleTalk and is destined for a nonextended Ethernet MEC interface. The workaround is to disable the AppleTalk route cache on either the MEC Ethernet interface or the FDDI interface. [CSCdi08211]
- The stopbits 1.5 command is never written to nonvolatile RAM or to remote network configuration files, even for lines that have been configured using it. [CSCdi05124]
- Entering multiple logging buffered commands without an intervening no logging buffered command can cause meaningless output to be included in the output of the show logging command. [CSCdi08459]
- System images from the 8.3, 9.0, 9.1, and 9.14 releases could not be successfully netbooted on IGS boxes with 8.2 EPROMs. The ROM monitor in the 8.2 EPROMs did not support some functions that the newer releases uses. The system image should protect itself by error checking the return code from all ROM monitor calls. [CSCdi08521]
- DECnet address translation fails on IGS platform routers in the cases where both interfaces are not fast switched and one of the interfaces is capable of being fast switched. The workaround is to configure both interfaces for DECnet fast switching. Since this is not possible for all interfaces and encapsulations such as Token Ring, X.25, and Frame Relay interfaces, some configurations cannot support ATG on IGS platform routers. [CSCdi07652]
- When routing IP in conjunction with bridging, HP Probe packets will be bridged rather than received by the router. Cisco Systems expects to resolve this problem in a future release. [CSCdi07039]
- When a remote Source-Route Bridge peer is removed, the unit may reload. [CSCdi08152]
- Output drops are double-counted when the output hold queue is full. [CSCdi07195]
- The debug ? command doesn't show serial options if the only serial interface type is HSSI. [CSCdi07674]
- The debug broadcast command does not work on FDDI broadcast packets unless the hidden debug fddi-event command is enabled. [CSCdi08137]
- 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]
- When reconfiguring the priority on an interface used for transparent bridging, we delay reconfiguring the port until we receive the following BPDU message. This can cause a significant delay in the convergence of the spanning tree. This caveat is present in all previous releases. The port is now reconfigured as soon as the configuration command is executed. [CSCdi08296]
- When using process PCM and dual-homing connection, if the user issues a cmt disconnect command to a standby port the CPU utilization will go very high. This was fixed in 9.1(1.5), 9.0(3.2), and 8.3(6.1). [CSCdi08427]
- An "event-dismiss" error message can be encountered when debug output is being output on the console while running a bootstrap system image, i.e., igs-rxboot, xx-rxboot, csc3-boot. [CSCdi08533]
- When a communication server line is configured for modem control and with a session timeout, the session timeout will not be honored if the line is running in SLIP mode. [CSCdi08562]
- On the IGS, 3000, and 4000 serial network interfaces, we check the status of DCD before we assert DTR. This means that loopback interfaces that connect our output DTR signal to our input DCD signal will not work, because DCD will never be asserted yet. We should assert DTR before checking for DCD. [CSCdi08612]
- When an IP packet with IP options is received on a fast-switching interface, the system sometimes fails to decrement the IP TTL before forwarding the packet. This is most noticeable when a "traceroute" program is being used with source-routing options, and causes the system to sometimes fail to show up as an intermediate hop in the traceroute output. [CSCdi08699]
- The clear counter [type unit] command always clears the counters regardless of the user's response to confirmation. [CSCdi08774]
- MCI/SCI will become unusable when the MTU is 4 Kbytes or above because there is only one buffer for the receive side. We recommend that MTU should be less than 4.5 Kbytes. This was fixed in 9.(3.4), 8.3(6.2), and 9.1(2.2). [CSCdi08842]
- When using the domain-list command, the software may fail to properly update domain cache entries that have been timed out. [CSCdi03896]
- 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]
- Static IP routes can fail to be removed from the routing table when an unnumbered interface goes down. This can result in host or network routes pointing to a down interface to continue to be advertised via routing protocols. When the interface goes down, the router should remove the static route from the routing table for as long as the interface remains down. Until fixed, static IP routes should not be used with unnumbered interfaces. [CSCdi08180]
- If an unnumbered interface is shut down, it is periodically removed from the IP routing table. This causes unnecessary routing table activity and can introduce other detrimental side effects. This problem was introduced in 9.1(1.3) and 9.0(3.1). [CSCdi08715]
- When a system is attempting to TFTP boot, it may not know a route to the TFTP server. If the system has multiple interfaces by which it might contact the TFTP server, it can fail to continue to use the interface on which the TFTP transfer was just established. The result is that TFTP tftp boot attempt fails. The system should remember by means of its arp table the interface to use to reach the TFTP server. Configuring the system's NVRAM so that it can only reach the server by one interface at boot time avoids this problem. [CSCdi09068]
- The "better SNPA" field in an ES-IS redirect is always sent in native bit order. This can cause OSI End Systems on Token Ring networks to be unable to reach some destinations when more than one router is present on the token ring. [CSCdi07200]
- The encapsulation type for CLNS is sometimes displayed incorrectly when a show clns interface command is entered. This is a cosmetic defect only. [CSCdi08467]
- CLNS fast switching does not properly fragment packets. Packets received on FDDI that are larger than 1497 octets will not be forwarded properly over serial and 802.3 interfaces. This isn't typically a problem, since CLNS packets are seldom this large. The workaround is to disable CLNS fast switching on the FDDI interface using the no clns route-cache command. [CSCdi08494]
- If the CLNS trace facility is used to trace a path that goes through another Cisco router on the same LAN, the second of the three trace packets may not work. This has no operational impact, other than causing a 3-second delay in the execution of the trace. [CSCdi08653]
- CLNP packets received by a router with a lifetime field of zero will be forwarded (with a lifetime of 255) if slow-switched. This has no operational impact whatever unless a host is emitting packets with a lifetime of zero. [CSCdi08654]
- When an invalid ER PDU is received, we should just discard it, without sending an ER PDU in response. [CSCdi09139]
- Any attempt to query an unimplemented SNMP MIB variable will cause the system to return the snmpEnableAuthenTraps variable. The correct behavior is to indicate that the variable requested is not available. This problem will be corrected in a future release. [CSCdi04806]
- A box with TR crashed with the following: [CSCdi05629]
IP-3-Desthost:src=200.2.3.1 dst=0.0.0.0
Null desthost Process="SNMP Server",level=0,pid=28
Traceback=23628 23364 2500e 26a14 269ae 26c00 391da 81bbc
- If enable use-tacacs is configured without defining a tacacs-server host, then any username/password combination will allow any user to enable. [CSCdi08070]
- On routers without NVRAM, part of the sequence used to determine IP addresses is to send a BOOTP request. The replies to these requests are being ignored. [CSCdi08893]
- TCP connections can exhibit long pauses in data delivery if the router is attempting to send data faster than the foreign host can use that data. This happens most often in cases of protocol translation, DSLC tunneling, remote source route bridging, and X.25 switching. [CSCdi07964]
- A recent VINES problem is causing VINES' clients to send broadcast StreetTalk packets. Because the Cisco router floods streettalk broadcasts, this can cause congestion in wide area links. This caveat changes the router code to only flood streettalk broadcasts sent from a server. [CSCdi08277]
- If a VINES SPP packet is addressed directly to a router, it will discard the packet twice producing a "Buffer in list" error message. This error is very unlikely, and is also harmless. [CSCdi08362]
- The router was fixed 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]
- 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. The fix for this behavior allows choosing between spanning tree explorers and all routes explorers on a per protocol basis. This is done via an extension to the multiring command. The new command syntax is
[no] multiring {protocol | all} [all-routes | spanning]
- The trailing all-routes and spanning keywords specify the explorer type to be used. The default is to use spanning tree explorers. [CSCdi09091]
- The router may occasionally send an ICP error message with an error code of zero. Receipt of this message can cause a Banyan server to drop some or all communications links passing through the router. [CSCdi09175]
- If a station is removed from an interface that uses one type of encapsulation and is added to another interface that uses a different encapsulation before the neighbor entry expires, communication to the station will never be reestablished. [CSCdi09294]
- 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 router to be 15 characters or fewer. [CSCdi09372]
- The ping command will display incorrect round trip times for 32-byte Novell IPX or XNS packets. Use larger sizes when sending IPX echoes from the router to obtain more accurate round trip times. [CSCdi07529]
- On media other than 802.x, the show xns interface command will display the wrong encapsulation type when the default encapsulation has been changed. For example, on an SMDS interface, show xns interface will display "XNS encapsulation is HDLC." It should only display XNS encapsulation types for 802.x media. [CSCdi07929]
- When a Cisco router has a large number of the same type of interfaces, the show novell cache and show xns cache commands will display the interface limited to nine characters, which allows only Ethernet 1 when it is in fact Ethernet 11. The initial 9.1 release changed this to ten characters, which corrects Ethernet names, but Token Ring will have a similar problem unless the length is eleven characters. [CSCdi08236]
- When a Cisco router generates an XNS error response packet, it is sent out with a source address equal to the original source of the packet that caused the error response. The source address should be that of the router itself. [CSCdi08377]
- In certain topologies, fast-switch looping of (Novell) multicast packets can occur when received on an interface which is active, but not configured for Novell. This is now corrected. [CSCdi08722]
- Certain Novell packets may be received and processed by the local interface when they have been sent by a misconfigured Client, Server, or Router. For example, a SAP Get Nearest File Server packet sent on network 0xA1 from a host whose network number has been misconfigured as 0xA2. These misconfigured packets should be ignored and counted as bad packets. In the Show Novell Traffic display, the packets pitched counter should be incremented when we receive one of these packets. [CSCdi09178]
This section describes possibly unexpected behavior by Release 8.3(5) that has been resolved in Release 8.3(6). Unless otherwise noted, these caveats applied to all 8.3 releases up to and including 8.3(5).
All the caveats listed in this section are resolved in Release 8.3(6).
- Cisco's implementation of IPtalk is intended to allow UNIX hosts running CAP (Columbia AppleTalk Package) using the non-native AppleTalk encapsulation (i.e., AppleTalk encapsulation inside IP datagrams) to communicate with an existing AppleTalk network. The Cisco implementation of IPtalk does not currently provide for router-to-router IP encapsulation tunnels. [CSCdi05452]
- In software Releases 8.3(3) and 9.0(1), a nonextended interface can become operational in spite of the fact that an adjacent and active neighbor has a different configuration. Although the interface becomes operational, connectivity through any routes controlled by that neighbor is lost. [CSCdi05642]
- Entering the command appletalk event-logging returns a spurious message:
"% One of "probe" or "request""
- This message can be ignored. [CSCdi05694]
- In large AppleTalk networks with large Phase 1 components, network numbers that would normally age out of routing tables may persist indefinitely. This is due in part to the lack of split-horizon processing in Phase 1 environments and changes made to the RTMP aging process in 8.3. One possible workaround is to apply access lists to block the invalid network numbers from being propagated using the appletalk distribute-list [in|out] command. Upgrading to Phase 2 extended operation on all networks also corrects the problem. [CSCdi05913]
- The following software problem manifests itself in two observable ways in the Appletalk component of the router software: The first is that once the router has been up for more than 24 and one-half days, clearing, resetting or reconfiguring an AppleTalk interface will cause the interface in question to attain a status of "Restart port pending" that will not change, no matter how the interface is configured or cleared. The second manifestation of this problem is cosmetic in nature. Times that are expressed as an interval of time, particularly in the output of the command, show appletalk neighbor, will show neighbor up times of "never" after the router has been up for 24 and one-half days or longer. The only workaround for this problem is to reload the router every three weeks. [CSCdi06929]
- The show appletalk command does not accept the talk portion of the keyword appletalk. This is not a serious problem, because it is easily worked around by using the keyword apple in EXEC commands. [CSCdi06988]
- The router does not change the source address it uses for syslog messages after the address is no longer valid. The correct behavior is for a new address to be selected. A workaround is to reload the router after a reconfiguration that has invalidated the address the router was using to source syslog messages. [CSCdi04906]
- If a user connected via Telnet to a router leaves the show process display at the --more-- prompt, and the virtual terminal session idle timer expires, a system reload can occur. [CSCdi05633]
- The get_pak_size string is missing support for huge buffers. There is no further information available concerning this problem. [CSCdi07091]
- On the 8.3, 9.0, and 9.1 releases, the Ethernet and serial interfaces on the IGS use larger buffers than is required if a Token Ring is configured in the system. This wastes shared (buffer) memory. On the 9.1 release, the Cisco 4000 also uses larger buffers than is required if a Token Ring Network Interface Module (NIM) is configured in the system. This problem will be fixed in a future release. [CSCdi07369]
- Configuring a location string longer than 69 characters can cause the system to reload. After configuring, the system prints out a message displaying where the system was configured from and gives the location. If the location is greater than 69 characters in length, it can cause a system reload. The correct behavior would be to truncate the location string. This will be implemented in a future release. [CSCdi07834]
- A Cisco router running DECnet Phase IV with conversion enabled does not ignore Phase IV hellos sent from a Phase V router. As such, the router will try to set up a Phase IV adjacency with the Phase V router, while the Phase V router ignores the Phase IV hellos that the Cisco router sends. In effect, this causes the adjacency to be one-way, and will show up in the Cisco router's DECnet IV routing table as initializing. [CSCdi07393]
- Cisco routers did not ignore Phase IV hellos sent by a router running Phase V (Cisco or DEC). This created problems when a DEC Phase V router was adjacent to a Cisco router, because the Cisco was accepting the DEC's Phase IV hellos while the DEC router was rejecting the Cisco Phase IV hellos. The result was incomplete Phase IV adjacency. Caveat 7393 added code to ignore Phase IV hellos from a Phase V router when running OSI and Phase IV with conversion turned on. This fixed the original problem, but it resulted in an interesting side effect: the Cisco router is now refusing Phase IV hellos from Cisco routers as well. This caused a DECnet Phase IV network to get partitioned when there were Cisco routers running with Phase IV, OSI, and conversion on. [CSCdi08164]
- The setup command does not allow CLNS station IDs containing a zero to be entered if an ID other than the default was desired. Possible workarounds include using the default station ID supplied, or using a station ID that does not contain a zero. [CSCdi06665]
- In early versions of the bridging software, IEEE BPDUs weren't always well formed. That is, TCN BPDUs would not get transmitted properly or at all. [CSCdi05981]
- The srb output-address-list list command is mistakenly applied to the source MAC address and not to the destination MAC address. [CSCdi06347]
- During process-level bridging, the nonflood bridge forwarding code does not check to make sure that it does not output a packet on the interface upon which it arrived. The behavior has been present in all versions of the router supporting process-level bridging. Normal transparent bridging does not notice this, as it runs fast switched and the check is correctly applied in the fast switching code. However, bridging that runs at the process level (SR/TLB, bridging with Priority Output, and bridging over X.25 or Frame Relay) runs into this problem. Symptoms of this problem are seen in packets that are duplicated on the receiving interface. The correct behavior is that packets should not be retransmitted on receiving interface. The impact is on certain protocols that are sensitive to packet duplication and that may not function properly. Process-level bridging performance will degrade. There are no known workarounds. Cisco expects to resolve this behavior in a future release of 8.3. [CSCdi06609]
- Router issues a %SYS-2-INTSCHED message and traceback when operating with debug rif enabled. The behavior has been present in all versions of the code supporting process-level bridging. After the command has been issued, the router may begin to display the message. The length of time depends upon how much traffic is presented to the router. Higher levels of traffic cause the problem to appear sooner. Once the condition has been triggered, the router continually sends error message and traceback information. The impact is a potential performance for process level activities. The workaround is to not use the debug rif command. The behavior has been present in all versions of the router supporting rif caching. This should be resolved in a future release of 8.3. [CSCdi06634]
- It is possible for a RIF entry to be updated by a received frame at the same time it is being used to generate a frame. In this case there is a possibility that a frame with a circular RIF will be generated. [CSCdi06673]
- When doing pure bridging, some forms of communication with the router/bridge using IP wouldn't work correctly. [CSCdi06687]
- Under rare conditions, it is possible for a race in the code for the show ip arp command to result in system reloads. This command should be used with care. [CSCdi02706]
- Shutting down interfaces that are members of a bridge group and are in a forwarding state, and then bringing them back up may result in forwarding loops in the spanning tree. These loops will manifest themselves in saturated traffic levels on the interfaces and excessive CPU utilization. Systems in this situation typically must be reloaded to recover normal operation. [CSCdi05010]
- TCP/IP ARP replies are sometimes bridged when both transparent bridging and IP routing are enabled. The conditions under which this occurs are not yet fully understood. [CSCdi05156]
- Keepalives will not bring back an Ethernet interface that is down (transceiver cable disconnected, cable unterminated, and so on) on a CSC/4 processor with an Ethernet MCI. For an Ethernet with keepalives enabled, a keepalive packet is sent every keepalive interval. In this scenario, if a user disconnects the transceiver cable to the Ethernet, and three keepalives were sent but not received, "line protocol" would go down, and the interface would be unusable, as expected. If the user then reconnects the transceiver cable, the correct behavior would be for the keepalives to bring the interface back up within the keepalive period. This does not happen with the CSC/4 processor. The interface remains down despite attempts to lengthen the keepalive period, generate more keepalives, or attempt to clear the Ethernet interface with the clear interface command. The workaround is to toggle the keepalives for that particular Ethernet interface using the no keepalive command, followed by the keepalive n command.
- Note: The only action that is required for the interface to come back up is to turn off keepalives. Turning them back on is optional, but doing this will correctly turn off "line protocol" if the line goes down in the future. [CSCdi05172]
- The router will reload if the interface subcommand bandwidth is set to zero. [CSCdi05964]
- show rif could cause a router to crash when the RIF cache is getting updated. This fix resolves the problem. [CSCdi06016]
- The router has problems netbooting when there are multiple paths to the remote TFTP server. [CSCdi06088]
- When bridging is enabled, SNAP encapsulated packets will be bridged even when the relevant routing protocols are enabled. Bridge filters may be used to constrain the propagation of this traffic by SAP, but no solution is available for receiving or routing these packets. [CSCdi06109]
- The router software decrements the reset counter after some internally generated interface resets, e.g. after the mac-address command has been issued. There is no check to see if the reset counter is zero before decrementing it, thus it is possible to decrement the counter to a negative value. Because the value is always displayed as an unsigned positive number, it shows up as a number near 4294967295. [CSCdi06490]
- In a spanning-tree environment for bridging, some transitions from Forwarding to Blocking wouldn't work correctly. This could result in inconsistent spanning-tree state with possible network outages resulting. [CSCdi06689]
- If a SMT frame comes in on the FDDI, the wrong thing happened and we would lose buffers. [CSCdi07080]
- Multicast FDDI packets that did not have a UI (0x03) control field would not get bridged at all. [CSCdi07107]
- In a bridge environment, ARP entries can be heard for a given node on either an FDDI or an Ethernet. If the node is on FDDI, we should keep it there but due to a bug we will hear it on Ethernet later and force it to change which causes communications to not take place. [CSCdi07139]
- When configured to encapsulate VINES packets with a SNAP header, the router currently uses the header AAAA.0300.0000.0BAD. This fix changes the code to use the proper header of AAAA.0300.0000.80C4. [CSCdi07196]
- In a pure bridged environment (i.e., IP is being bridged rather than routed), under different topologies other nodes would sometimes not be able to communicate directly to the Cisco router. This includes SNMP and Telnet traffic. This makes the router effectively unmanageable. [CSCdi07417]
- When routing IP in conjunction with transparent bridging, 802.3 SNAP encapsulated IP will be bridged rather than routed. Cisco Systems expects to resolve this problem in a future release. [CSCdi07495]
- In a bridged environment there were a number of bugs that would cause various failures. This included not garbage collecting bridge table entries at the proper time as well as some corner cases in the spanning-tree transitions. [CSCdi07532]
- When there is a single fiber break or the neighbor station sends constant halt line state (HLS), system CPU utilization will reach 100 percent. [CSCdi07682]
- When the Cisco router receives an IEEE 802.2 TEST and XID frame that contains both a RIF field that indicates that the frame should traverse the Cisco router, and a destination address that indicates that the frame should terminate at the Cisco router, the Cisco router chooses to terminate the frame and reply to it, if needed. This is not in compliance with a strict definition of source-route bridging. This is a minor problem that has little, if any, actual functional impact in most source-bridged networks. This problem will be fixed in a future release. [CSCdi07722]
- A bridge configured with no bridge acquire will continue to flood and forward packets for other than statically configured MAC addresses. In some cases, bridge filters may be used instead to achieve the desired pattern of traffic containment. [CSCdi07934]
- When the system is bridging IP, ARPs originated by the system cause an error message to be generated. This behavior is seen only with packets originated by the system and impacts the use of IP for management of a bridge with a frame relay interface. [CSCdi08293]
- Under certain circumstances a pure IP bridge (no ip routing) wouldn't be able to communicate with other IP hosts in the presence of topology changes. [CSCdi08349]
- If RIP is run across an unnumbered link, and the associated numbered interface has a nondefault broadcast address, the RIP updates on the unnumbered links will have an incorrect checksum generated. The workaround is to use the default broadcast address on the associated numbered interface. [CSCdi04838]
- ARP requests generated on FDDI by systems which are bridging IP are sent using the common FDDI SNAP encapsulation. Other systems on the FDDI ring will not bridge these packets onto Ethernets which may be connected to them, and ARP table entries will therefore never be learned for systems on those Ethernets. The correct behavior is to use the Ethernet-over-FDDI encapsulated bridging format for ARP packets generated on FDDI by units bridging IP. [CSCdi05482]
- Configuring ip route 0.0.0.0 null 0 will result in the route showing up multiple times in the routing table. [CSCdi05754]
- If routers using secondary addresses are inconsistent about the primary address, routing updates are not generated correctly. [CSCdi05942]
- RIP, HELLO, and IGRP advertisements being broadcast on unnumbered serial links will not advertise the major network number of the associated numbered interface. [CSCdi06205]
- CSCdi05488 caused the router to not send complete RIP updates to explicitly configured RIP neighbors. [CSCdi06285]
- If split horizon is disabled and the interface is numbered, the router should not accept IGRP, RIP, or HELLO routing updates from other hosts on that interface but not on the subnets configured on that interface. [CSCdi06885]
- In very rare circumstances, EGP can cause a router to reload if another process attempts to clear the IP routing table while an EGP update is being processed. [CSCdi07587]
- If extended access lists are used on an MCI, SCI, or ciscoBus interface, the IP route cache is enabled, and the established keyword is used, the access list can be improperly evaluated. This can permit packets that should be filtered and exclude packets that should be permitted. This behavior was first introduced in 8.2. [CSCdi07901]
- Issuing the command clear clns route may cause a system reload to occur. [CSCdi05343]
- CLNS does not support both static and dynamic routing simultaneously within a router. [CSCdi05893]
- Forwarding a converted DECnet Phase IV packet causes a DECnet Phase V redirect. For example, a CLNS packet is received on an interface. It is converted into a DECnet Phase IV packet, which is then sent back out the interface, and an ES-IS redirect PDU is erroneously sent. [CSCdi06121]
- In some CLNS displays, when an X.121 address is displayed, an 8 digit is printed as 0 and a 9 digit is printed as 1. [CSCdi06308]
- When an NSAP address with length of 0 is present in a CLNS packet, the fast switching routines corrupt memory and cause the system to reload. [CSCdi06370]
- When a CLNS area is deleted, the process associated with the area's domain is deleted, even if other areas exist in the domain. In effect, this will leave orphan areas. [CSCdi06666]
- The system does not properly fragment CLNP packets in some cases. If the packet length is slightly larger than the MTU of the outgoing subnetwork, the packet may either be sent as-is (oversized), or it may have a short final fragment (the ISO 8473 standard requires all fragments to carry at least eight octets of data). This may cause packets to be undeliverable if the receiving End System enforces the final fragment size requirement or if the packet is sent with a size greater than the subnetwork MTU. [CSCdi07646]
- The sysLocation is read-only. As a workaround, the location can be set with the snmp-server location configuration command. [CSCdi07909]
- If an interface is shut down and assigned an IP address, then the router should ignore that interface when trying to determine if it is on the same subnet as various other IP addresses. This affects various calculations, notably BGP NEXT_HOP calculations. [CSCdi05356]
- UDP echo requests are only responded to correctly for the first request received. Subsequent responses will be sent to the initial requesting address, regardless of who issues the request. The correct behavior is for the response to be sent to the address making the request. [CSCdi05721]
- The service tcp-keepalive command only applies to terminal ports and VTYs. [CSCdi05905]
- UDP port filtering is only done on packets arriving with a media broadcast indication. Consequently, the UDP port filtering mechanism ip forward protocol udp is ignored when receiving packets from nonbroadcast media such as X.25 and some frame relay networks. [CSCdi06001]
- In some cases the router sends TFTP ACK responses after an out-of-order packet has been received by a client while netbooting. If the server is busy, this event is quite possible. Sending a second ACK response causes the client and server to get into an argument over what packet to send, and in many topologies it will fail. Common cases look like the following example: [CSCdi06319]
!!!!!!.O.........[timeout]
!!!!!!OOOOOOOOO!OOOOOOOOOO!OOOOOOOOOO!OOOO....[timeout]
!!!!!!.!O...... [timeout]
- Server discovery broadcasts received on interfaces configured with the vines serverless command are always forwarded to the nearest server listed in the routing table. The nearness of the server in question is calculated from the router's point of view, rather than from the point of view of the client. This behavior may cause overloading of the nearest server, while other servers are left underutilized. Resolution: When a server discovery broadcast is forwarded onto the network containing the nearest server, it will be forwarded as a MAC layer broadcast. This means that all servers on that physical network will see and respond to this frame, instead of one single server. There is also a change to the output of show vines route, so you can easily see which VINES server is considered the nearest one. The new output is as follows:
4 routes, next update 77 seconds Codes: R - RTP derived, C - connected, S - static
RN Net 0027AF9A [2] via 0027AF9A:1, 10 sec, 0 uses, Ethernet0 C Net 30004355 is this router's network, 0 uses R Net 002ABFAA [2] via 002ABFAA:1, 10 sec, 0 uses, Ethernet0 R Net 3000FB06 [1] via 3000FB06:1, 8 sec, 0 uses, Fddi0
- where the capital letter "N" indicates that this server is the nearest server, and it is on the local network. The lowercase letter "n" is used to indicate that this server is considered the nearest server, but it is not on the local network. [CSCdi02868]
- It is possible, but unlikely that you can crash the router while running the command show vines route. If you issue this command and let the display sit at the --More-- prompt until the last route displayed expires from the routing table, the router will crash when you press the space bar to continue. This caveat fixes this problem. [CSCdi05330]
- This problem occurs when a server is moved from one physical cable segment to another, and both cable segments are connected to a router. The router must expire the neighbor entry for the old cable before it can learn a new entry for the new cable. During this period, as it receives routing updates on the new interface, it continues to process them even though they do not match the current neighbor entry for the server. [CSCdi06994]
- The router needs to provide the ability to disable split horizoning of VINES routing updates. This is needed to build a VINES network over a nonbroadcast media, such as frame relay, when there is not complete connectivity between all nodes in the network. [CSCdi07034]
- The router needs to provide quicker learning of alternate route when an interface goes down. [CSCdi07037]
- When operating in serverless mode, some customers need the ability to flood a received broadcast to all other interfaces instead of choosing the best interface and sending the frame. This bug fix adds this capability and the supporting code so it may be configured. [CSCdi07599]
- An interface input queue may fill up and not recover if an X.25 provider violates the LAPB protocol by exiting from the RNR state with an RR frame instead of an REJ frame. This can cause the serial interface to pause indefinitely and cease transmission. [CSCdi05957]
- The error message and traceback:
%X25-3-INTIMEQ Interface [chars], LCN [dec] already in timer queue, new time [dec]
- is used as a diagnostic aid; although an unexpected condition was detected and reported, the operation of the router and the X.25 protocol are not affected. If this message is produced, contact Cisco Systems and include the text and traceback of this message as well as the information from the show version command. [CSCdi07238]
- When we miss a SAP update, we mark the entry as poisoned but if a subsequent SAP update is received we never remove it from the poisoned state so the SAP entry will always time out, even if only one update was missed. This problem has always existed but another patch added recently (CSCdi05359) has now exacerbated this previously unnoticed bug. [CSCdi06315]
- Correct usage of Novell/XNS/Apollo transportControl (hop count) field, read/increment only hop count bits, discard packet when 16th router reached (hop count = 15, *not* 16), preserve reserved bits as packet transits router, minimize impact on Novell fast-switching code when reserved bits are 0 (the normal case). [CSCdi06340]
This section describes possibly unexpected behavior by Release 8.3(4). Unless otherwise noted, these caveats apply to all 8.3 releases up to and including 8.3(4). For additional caveats applicable to Release 8.3(4), see the caveats sections for newer 8.3 releases. The caveats for newer releases precede this section.
All the caveats listed in this section are resolved in Release 8.3(5).
- AARP packets from nodes in the startup range are rejected as "martians," preventing nodes from acquiring their initial configuration when connected to a new network. The workaround is to have at least one router on the cable that is not running version 8.3(4). [CSCdi06137]
- After a system has been operational for 24 days, the IGRP, RIP, HELLO and CHAOS routing processes stop sending updates. The cessation occurs when the routing process has been running the entire time the system has been operational or when the process is manually started any time after system start up. There is a workaround for IGRP. Assuming nondefault values for the IGRP timers, use the router subcommand timers basic 90 270 280 630 1. The only value that helps the workaround case is setting the fifth parameter equal to 1. The other values do not affect the problem and should be set according to the users' needs. The above example is the normal case. A workaround does not exist for RIP, HELLO, and CHAOS. [CSCdi06310]
This section describes possibly unexpected behavior by Release 8.3(3). Unless otherwise noted, these caveats apply to all 8.3 releases up to and including 8.3(3). For additional caveats applicable to Release 8.3(3), please see the caveats sections for newer 8.3 releases. The caveats for newer releases precede this section.
All the caveats listed in this section are resolved in Release 8.3(4).
- If the initial address given for an AppleTalk interface does not agree with that interface's cable range, the port may be driven into a continuous reset state. The correct behavior is to reject the attempt to configure an invalid address and issue an error message. [CSCdi03924]
- AppleTalk does not correctly track changes to the encapsulation type set on a serial interface. To workaround this problem, clear the AppleTalk configuration on the interface and reconfigure. [CSCdi04609]
- The informational level message, AT-6-ADDRUSED, will display gibberish numbers for the AppleTalk address in use for the interface in question. [CSCdi04706]
- The system will permit configuration of AppleTalk cable ranges on serial interfaces with SMDS and frame relay encapsulations. In fact, extended networks are not supported for such interfaces. [CSCdi04771]
- In certain unusual circumstances, the router can fail to acquire zone information from neighbors for valid routes. This results in partial loss of connectivity. Turning off AppleTalk and/or restarting the router may act as a workaround. [CSCdi04999]
- When an AppleTalk ARP reply is received on a Token Ring interface, the sanity check that prevents entering multicast MAC addresses into the ARP table is done incorrectly; the least-significant bit of the first octet of the address is checked instead of the most-significant. This may result in the system accepting invalid AppleTalk ARP replies, or, usually more seriously, in its ignoring valid ones. This can be worked around by reconfiguring other nodes to use Token Ring MAC addresses that do not have the least significant bits set in their first octets. [CSCdi05167]
- A system reload of a router may occur under very rare circumstances while performing a show apple arp command as a result of an ARP table entry being removed while the show apple arp command was traversing the ARP table. [CSCdi05232]
- This bug would affect the ability of a nonextended AppleTalk interface in discovery mode to start when there is only a Shiva FastPath on the cable to perform the function of seed router. If there is already some router other than a Shiva FastPath on the cable, the interface will start routing as expected. [CSCdi05440]
- The show conf displays the following buffer numbers:
buffers small min-free 20
buffers middle min-free 10
buffers big min-free 5
- Extra lines of default buffers clutter the NVRAM listing. If a user does a write memory command, it will save this config to the NVRAM. This will cause them to stay permanently in your configuration even in future releases. A user must use the no commands for each line to clear the extra messages. [CSCdi04904]
- CLNS hosts do not increment the line count correctly in the show host display. Consequently, the command does not respect the term length n settings. [CSCdi05083]
- If during setup user input is delayed, a possible timeout will occur. The router will then loop indefinitely requesting user input. However no input will be accepted. At this point, the router would have to be reloaded to clear the condition. [CSCdi04427]
- When setup is used to configure a router, the router igrp command is removed from the configuration file on reload. The workaround is to modify the configuration file by hand and add back the missing command. [CSCdi04641]
- The command service exec-wait, which causes the EXEC process to wait if there is input pending on a modem line, has been implemented. This command is intended as a workaround for problems with modems sending junk characters during various types of speed negotiation. The command is disabled by default. [CSCdi04852]
- SRB proxy explorer does not work. [CSCdi04671]
- The no bridge n address command does not work properly. Although the specified entry is removed, the configuration is modified so that bridge n address commands for stations that were not previously modified are introduced. [CSCdi04700]
- Path costs for Spanning Tree Protocol not recomputed when enabling DEC spanning tree protocol. A potential side-effect of this is that interfaces configured for bridging after the bridge n proto dec command has been issued may have different path costs than those configured before the command. [CSCdi05251]
- Under certain conditions on the token ring interface (generally high traffic or noisy media), a message similar to
%TR-3-RESETFAIL: Unit 0, reset failed, error code 00007F32. -Traceback= 97F84 97CFA 970A2 96FBE 9C5E8 12766 37F8 1D1E
- may appear, indicating that the token ring interface was unable to reset itself. [CSCdi05644]
- When multiple IP helper addresses are defined, broadcast packets going out the first interface in the list could be sent with bad checksums. [CSCdi04326]
- Incoming connections fail to return to default settings once the session is terminated. [CSCdi04522]
- The no priority-group command does not accept a number argument. For instance, the command no priority-group 10 would incorrectly generate an error. [CSCdi04527]
- AppleTalk does not work over Frame Relay in 8.3(2) and 8.2(3). [CSCdi04547]
- When multiple connections come very quickly for the same port, a race condition can occur which will cause a system reload. [CSCdi04569]
- If the frame relay map command is issued before the encapsulation frame relay command, then no action is taken. This is the correct behavior, so although no action is taken, no error message is generated. Not generating an error message in this case was incorrect; an error message is now generated. [CSCdi04576]
- Very high average output rates can result in overflows in the computation of the 5-minute data rates in the show interface command display. This manifests itself as the appearance of nonsensically large values. [CSCdi04665]
- Attempts to se
