cc/td/doc/product/software
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Channel Interface Processor Microcode Release Note and Microcode Upgrade Requirements

Channel Interface Processor Microcode Release Note and Microcode Upgrade Requirements

February 2, 1998

This document contains the release notes for the unbundled CIP microcode software. Prior to Cisco Internetwork Operating System (Cisco IOSTM) Release 11.1, CIP microcode was provided as part of the Cisco IOS software "bundle." Beginning with Cisco IOS Release 11.1 and continuing with all subsequent Cisco IOS software releases, the CIP microcode was unbundled from the Cisco IOS software. Therefore, you can obtain the CIP microcode as a separately loadable software module and match a version of the CIP microcode to the Cisco IOS software.

Refer to the "CIP Microcode and CIP Hardware Compatibility" section for a list of CIP microcode releases described by this document..


Caution If you are upgrading from a previous Cisco IOS release, a special microcode installation procedure is required or your CIP will not operate properly. For details, refer to the section "CIP Microcode Upgrade Overview."

Introduction

This CIP microcode release note describes the CIP microcode modifications and caveats for the latest versions of CIP microcode. It includes all CIP microcode releases described in the section "CIP Microcode and CIP Hardware Compatibility." Also included is an overview of the procedures required to upgrade to the latest versions of CIP microcode depending on the CIP-compatible router platform you have.

This CIP microcode release note discusses the following topics:

Cisco IOS Software and Cisco 7000 Family Hardware Documentation

For documentation of CIP features in the Cisco IOS 11.1 Release, refer to Table 1.


Table  1: Cisco IOS 11.1 Release Publications
Cisco IOS 11.1 Release Publication Customer Order Number
Configuration Fundamentals Configuration Guide DOC-CFCG11.1=
Configuration Fundamentals Command Reference DOC-CFCR11.1=
Bridging and IBM Networking Configuration Guide DOC-IBMNCG11.1=
Bridging and IBM Networking Command Reference DOC-IBMNCR11.1=
Cisco IOS Software Command Summary DOC-CIOSCS11.1=
System Error Messages DOC-SYSEM11.1=
Release Notes for Cisco IOS Release 11.1 Document Number 78-2886-xx

For documentation of CIP features in the Cisco IOS 11.2 Release, refer to Table 2.


Table  2: Cisco IOS 11.2 Release Publications
Cisco IOS 11.2 Release Publication Customer Order Number
Configuration Fundamentals Configuration Guide DOC-CFCG11.2=
Configuration Fundamentals Command Reference DOC-CFCR11.2=
Bridging and IBM Networking Configuration Guide DOC-IBMNCG11.2=
Bridging and IBM Networking Command Reference DOC-IBMNCR11.2=
Cisco IOS Software Command Summary DOC-CIOSCS11.2=
System Error Messages DOC-SYSEM11.2=
Release Notes for Cisco IOS Release 11.2 Document Number 78-3648-01-xx

For documentation of CIP features in the Cisco IOS Release 11.2 BC, refer to Table 3.


Table  3: Cisco IOS Release 11.2 BC Publications
Cisco IOS Release 11.2 BC Publication Customer Order Number
Release Notes for Cisco IOS Release 11.2 78-3648-xx
Release Notes for Cisco IOS Release 11.2 BC 78-4694-xx
Feature Guide for Cisco IOS Release 11.2 BC 78-4693-xx

For documentation of CIP features in the Cisco IOS Release 11.3, refer to Table 4.


Table  4: Cisco IOS Release 11.3 Publications
Cisco IOS 11.3 Release Publication Customer Order Number
Configuration Fundamentals Configuration Guide DOC-CFCG11.3=
Configuration Fundamentals Command Reference DOC-CFCR11.3=
Bridging and IBM Networking Configuration Guide DOC-IBMNCG11.3=
Bridging and IBM Networking Command Reference DOC-IBMNCR11.3=
Cisco IOS Software Command Summary DOC-CIOSCS11.3=
System Error Messages DOC-SYSEM11.3=
Release Notes for Cisco IOS Release 11.3 Document Number 78-4998-xx

For chassis-specific hardware configuration or troubleshooting information, refer to the following publications:

These hardware publications are available on Cisco Connection Online in the Core/High-End Routers database.

How Does CIP Microcode Ship?

For the Cisco 7000 family routers (Cisco 7000 series routers and Cisco 7500 series), CIP microcode is available on floppy disks, Flash memory cards (which also include the Cisco IOS release compatible with the microcode version), and via Cisco Connection Online (CCO).

Starting with Cisco IOS Release 11.1, CIP microcode images are shipped separately from the Cisco IOS software. For new Cisco 7000 family routers shipped with Cisco IOS Release 11.1 and later, the CIP microcode is shipped pre-installed on the Flash memory card. For Cisco IOS Release 11.1, 11.2, and 11.2 BC software upgrades, the CIP microcode is shipped or available on the following media:

CIP Microcode and CIP Hardware Compatibility

Beginning with Cisco IOS Release 11.1(5), shipping in August 1996, two versions of the CIP card are supported. Production of the initial CIP card has been discontinued and it can no longer be ordered. The CIP2 card replaces the CIP.

There are no microcode issues associated with this change. The Route Switch Processor (RSP) card in the Cisco 7000 family router automatically determines which version of the microcode is appropriate for the installed CIP or CIP2.

Cisco IOS Release 11.1(5) and CIP microcode Version 22.6 as well as Cisco IOS Release 11.2(2) and CIP microcode Version 22.7 support both a CIP and a CIP2 card in the same router. Prior to this release, different versions of a CIP card in the same router are not supported.

CIP Microcode/Cisco IOS Software Compatibility Matrix

Table 5 lists CIP microcode version and Cisco IOS software compatibility for the Cisco 7000 family. The CIP microcode image is shipped in a bundle separate from the Cisco IOS software images.

Note Starting with Cisco IOS Releases 10.3(9) and 11.0(5), the Cisco 7000 series routers and the Cisco 7500 series routers use the same CIP microcode image. The first version of common CIP microcode in Cisco IOS Release 10.3 is cip20-5, in Cisco IOS Release 11.0 it is cip21-3. Cisco IOS Release 11.1 and later all use the common CIP microcode rather than a separate microcode version for each chassis and processor type.

Table 5: Unbundled CIP Microcode Releases and Corresponding Cisco IOS Releases for the Cisco 7000 Family
Default CIP Microcode Version Cisco IOS Release 11.1 Cisco IOS Release 11.2 Cisco IOS Release 11.2 BC Cisco IOS Release 11.3
21-3 11.1(1)
22-0 11.1(1)
22-3 11.1(3)
22-6 11.1(5)
22-7 11.1(6)
22-10 11.1(7) 11.2(1), 11.2(2)
22-12 11.1(8) 11.2(3), 11.2(4)
22-14 11.1(9)
22-15 11.1(10)
22-17 11.2(5)
22-18 11.1(11)
22.19 11.2(6)
22-20 11.1 (12 11.2(7)
22.21 11.1 (13) 11.2(8)
22-22 11.1(14) 11.2(9)
22-23 11.1(15)
22-25 11.1(16) 11.2(10)
22-26 11.1(17) 11.2(11)
24-0 11.2(8)BC
24-1 11.2(9)BC
24-2 11.2(10)BC
24-3 11.2(11)BC
25-3 11.3(1)
Note For Cisco IOS Release 11.2 BC, the CIP card is supported only on the Cisco 7000 with RSP7000 and the Cisco 7500 series routers.

CIP Microcode Release cip25 Caveats and Modifications

CIP Microcode Version 25.3 is the initial release for support under Cisco IOS Release 11.3(1). Because CIP Microcode Version 25.3 was based on Version 25.2, modifications made in Version 25.2 are listed below.

Caveats for Version 25.2/Version 25.3 modifications

This section describes possibly unexpected behavior by Version 25.2. All the caveats listed in this section are resolved in Version 25.3. See Table 5 for the Cisco IOS software release that corresponds to the 25.3 microcode version.

The workaround is to configure the CIP TN3270 PUs connecting at the host. [CSCdj07152]
The following is an example of the output: 
lorikeet#sh ext ch 2/2 tn dlur
 dlur MPX.LORICP                                 
 preferred dlus MPX.NGMVMPC             dlur-dlus status ACTIVE  
 current server MPX.NGMVMPC              cp-cp status ACTIVE
 backup dlus  
 preferred server  
  
 lsap token-adap  0 C0     vrn       status ACTIVE           
 link TRP390               remote 4000.7470.00e7 08  status ACTIVE
[CSCdj19544] 
Jul  4 00:10:28: %CIP25-6-MSG: %MSG802-6-LLC_DUP_SAP: LLC Duplicat SAP on interface 546 : SAP=4.
Issuing the llc show all command on the CIP indicates that CSNA has failed to clear up one remaining session. 
CIP-Slot5#llc show all
--- AdapNo 02, LanType Token     , SAP 04 ---
pcep=0860 rmac=4000.0000.7190 lmac=C000.0115.6500 rsap=04 lsap=04 this=8120EDA8
pcep=0860 state=ADM rbusy=no  lbusy=no  flow=on  pflag=1 dflag=0 v_r=0    v_s=0    last_nr=0    flag=60264282

The workaround is to issue a microcode reload command to clear the hanging session. [CSCdj26081]
The workaround is to issue the no csna command on the nonfunctioning subchannel, the no shutdown command on the physical interface, or the micro reload command. [CSCdj38712]
The workaround is to use PU names that are less than eight characters. [CSCdj39358]
[CSCdj41342]
The workaround is to inactivate the SNA local node before shutting down the virtual interface. [CSCdj43833]
The workaround is to either inactivate the local node first, or inactivate and then reactivate node when the problem occurs. [CSCdj46294]

Caveats for Version 25.1/Version 25.2 modifications

This section describes possibly unexpected behavior by Version 25.1. All the caveats listed in this section are resolved in Version 25.2.

This malfunction could be caused by the following:

  • TN3270 clients not following the RFC allow network virtual terminal (NVT) messages to be sent at disconnection time to inform the client of reason for disconnection.

  • Client TCPIP stack reorders the data and FIN (finish) packets causing an error on the client.

The workaround is to upgrade to a client TCPIP stack and application that conform to RFCs.
This error disables the capabilities of the Telnet option, which stops TN3270 mode (IAC DONT BINARY IAC WONT BINARY) and the NVT messages at disconnect time in CIPTN3270 server. [CSCdj19545] 
%CIP0-3-MSG: %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../ssi/ssi_buff.c @ 158 - (msg) && ((( msg)->m_flags & ( M_PK
%CIP0-3-MSG: THDR | M_EXT)) == ( M_PKTHDR | M_EXT))
[CSCdj23424]
The workaround is to handle multiple chain messages as if they are definite responses from the host while generating TN3270E header. This workaround will ensure that the definite-response from the host can be used to guarantee an end-to-end response. [CSCdj24073]
For the TN3270E client, there is no warning message if the host does not send a start data traffic (SDT) message. If a Telnet instead of a TN3270 client connects in the connection will fail, but an LU may be permanently assigned and not be reused again. If the host sends a DACTPU message, the statistics of the LU connections and disconnections may be wrong.
Some hosts may send system services control points (SSCP) LU data before they send notify-response data. Also, a "no bind" warning message may be sent. [CSCdj24694] 
%DEBUGGER-0-STACK_DATA8: 0000  FFFFFFFF BE810000 00000000 00000100  ...
If the second double word on this line contains 00000000 00000100 it is likely that the crash was caused by this bug. [CSCdj25062] 
SSI_ASSERT failure in ../cta802/ccb802.c @ 3044 - LOOPBACK_FLOW_RECEIVED
Fatal error (code=09)
[CSCdj29175] 
%DEBUGGER-0-STACK_DATA8: 0000  FFFFFFFF 803F0010 00000000 00010001  ...

If the second double word on this line contains 00000000 00010001 it is likely that the crash was caused by this bug. [CSCdj30387]
This bug is a regression caused by CSCdj28167. It occurs if the last message the host sends does not have end bracket (EB) bit on it. [CSCdj30937] 
Jul 30 00:53:29: %CIP3-3-MSG: %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../cta/cta.c @ 345 - FALSE
Jul 30 00:53:29: %CIP3-0-MSG: %DEBUGGER-0-FATAL_ERROR: Fatal error (code=09)
[CSCdj30949]
There is no guaranteed workaround other than to avoid random disconnection from the client in the middle of transactions. [CSCdj31131]
The workaround is to drop the duplicate request. [CSCdj31238]
For example, the interface works well if it is brought up with 6000 sessions. However, when the interface is issued a shutdown and no shutdown command, an additional 64K 160-byte buffers is added to one of the CTA buffer pools, consuming about 10 MB of memory. This excessive memory consumption causes various problems depending on the size of the CIP memory. The size of the buffer pool can be corrected by issuing a micro reload command. [CSCdj31884]

CIP Microcode Release cip24 Caveats and Modifications

CIP Microcode Version 24.0 is the initial release for support under Cisco IOS Release 11.2(8)BC. Because CIP Microcode Version 24.0 was based on Version 23.2, modifications made in Version 23.2 are listed below.

Caveats for Version 24.2/Version 24.3 modifications

This section describes possibly unexpected behavior by Version 24.2. All the caveats listed in this section are resolved in Version 24.3. See Table 5 for the Cisco IOS software release that corresponds to the 24.3 microcode version.

The workaround is to either not use sysreq or to reconnect the client if a SSCP-LU session is required. [CSCdj21850]
[CSCdj41342]
The workaround is to recycle the PU. [CSCdj46065]
The workaround is to recycle the TN3270. [CSCdj50517]
There is no workaround. [CSCdj51076]
The workaround is to revert to a previous CIP microcode version or install the next release, which does not contain this problem. [CSCdj51725]
The workaround is to reconnect the client. [CSCdj58664]
Another problem that was fixed was an OFFL-6-WRCHAIN error message when running TPF Offload. [CSCdj59133] 
SSI_ASSERT crash in ssi_msg_offset function.

The workaround is to reduce the PIU size. [CSCdj61634]
There is no workaround. [CSCdj64309]

Caveats for Version 24.1/Version 24.2 modifications

This section describes possibly unexpected behavior by Version 24.1. All the caveats listed in this section are resolved in Version 24.2. See Table 5 for the Cisco IOS software release that corresponds to the 24.2 microcode version.

The workaround is to inactivate the SNA local node before shutting down the virtual interface. [CSCdj43833]
The workaround is to revert to a previous CIP microcode version or install the next release, which does not contain this problem. [CSCdj51725]

Caveats for Version 24.0/Version 24.1 modifications

This section describes possibly unexpected behavior by Version 24.0. All the caveats listed in this section are resolved in Version 24.1. See Table 5 for the Cisco IOS software release that corresponds to the 24.1 microcode version.

The workaround is to configure the CIP TN3270 PUs as connecting at the host. [CSCdj07152]
This malfunction could be caused by the following:

  • TN3270 clients not following the RFC allow network virtual terminal (NVT) messages to be sent at disconnection time to inform the client of reason for disconnection.

  • Client TCPIP stack reorders the data and FIN (finish) packets causing an error on the client.

The workaround is to upgrade to a client TCPIP stack and application that conform to RFCs.
This error disables the capabilities of the Telnet option, which stops TN3270 mode (IAC DONT BINARY IAC WONT BINARY) and the NVT messages at disconnect time in CIPTN3270 server. [CSCdj19545] 
%CIP0-3-MSG:%SSI802-3-FATAL_ERROR: SSI_ASSERT failure in../ssi/ssi_buff.c @ 158 - (msg) && ((( msg)->m_flags & ( M_PK
%CIP0-3-MSG: THDR | M_EXT)) == ( M_PKTHDR | M_EXT))
[CSCdj23424]
The workaround is to handle multiple chain messages as if they are definite responses from the host while generating TN3270E header. This workaround will ensure that the definite-response from the host can be used to guarantee an end-to-end response. [CSCdj24073]
For the TN3270E client, there is no warning message if the host does not send a start data traffic (SDT) message. If a Telnet instead of a TN3270 client connects in the connection will fail, but an LU may be permanently assigned and not be reused again. If the host sends a DACTPU message, the statistics of the LU connections and disconnections may be wrong.
Some hosts may send system services control points (SSCP) LU data before they send notify-response data. Also, a "no bind" warning message may be sent. [CSCdj24694] 
%DEBUGGER-0-STACK_DATA8: 0000  FFFFFFFF BE810000 00000000 00000100  ...
If the second double word on this line contains 00000000 00000100 it is likely that the crash was caused by this bug. [CSCdj25062] 
Jul  4 00:10:28: %CIP25-6-MSG: %MSG802-6-LLC_DUP_SAP: LLC Duplicat SAP on interface 546 : SAP=4.
Issuing the llc show all command on the CIP indicates that CSNA has failed to clear up one remaining session. 
CIP-Slot5#llc show all
--- AdapNo 02, LanType Token     , SAP 04 ---
pcep=0860 rmac=4000.0000.7190 lmac=C000.0115.6500 rsap=04 lsap=04 this=8120EDA8
pcep=0860 state=ADM rbusy=no  lbusy=no  flow=on  pflag=1 dflag=0 v_r=0    v_s=0    last_nr=0    flag=60264282

The workaround is to issue a microcode reload command to clear the hanging session. [CSCdj26081] 
SSI_ASSERT failure in ../cta802/ccb802.c @ 3044 - LOOPBACK_FLOW_RECEIVED
Fatal error (code=09)
[CSCdj29175] 
%DEBUGGER-0-STACK_DATA8: 0000  FFFFFFFF 803F0010 00000000 00010001  ...
If the second double word on this line contains 00000000 00010001 it is likely that the crash was caused by this bug. [CSCdj30387]
This bug is a regression caused by CSCdj28167. It occurs if the last message the host sends does not have end bracket (EB) bit on it. [CSCdj30937] 
Jul 30 00:53:29: %CIP3-3-MSG: %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../cta/cta.c @ 345 - FALSE
Jul 30 00:53:29: %CIP3-0-MSG: %DEBUGGER-0-FATAL_ERROR: Fatal error (code=09)
[CSCdj30949]
There is no guaranteed workaround other than to avoid random disconnection from the client in the middle of transactions. [CSCdj31131]
For example, the interface works well if it is brought up with 6000 sessions. However, when the interface is issued a shutdown and no shutdown command, an additional 64K 160-byte buffers is added to one of the CTA buffer pools, consuming about 10 MB of memory. This excessive memory consumption causes various problems depending on the size of the CIP memory. The size of the buffer pool can be corrected by issuing a micro reload command. [CSCdj31884]
The workaround is to issue the no csna command on the nonfunctioning subchannel, the no shutdown command on the physical interface, or the micro reload command. [CSCdj38712]
The workaround is to use PU names that are less than eight characters. [CSCdj39358]

Caveats for Version 23.2/Version 24.0 Modifications

This section describes possibly unexpected behavior by Version 23.2. All the caveats listed in this section are resolved in Version 24.0. See Table 5 for the Cisco IOS software release that corresponds to the 24.0 microcode version.

A workaround is to examine the event log (located above the SNA traces). The event log shows whether the reply PSID response was received from the host. [CSCdi89304] 
%DEBUGGER-0-FATAL_ERROR: Fatal error (code=32)
This failure has only been observed at sites running the CIP across an SRB network to a host (instead of the normal channel attachment). [CSCdj17365]
This malfunction could be caused by the following:

  • TN3270 clients not following the RFC allow network virtual terminal (NVT) messages to be sent at disconnection time to inform the client of reason for disconnection.

  • Client TCPIP stack reorders the data and FIN (finish) packets causing an error on the client.

The workaround is to upgrade to a client TCPIP stack and application that conform to RFCs.
This error disables the capabilities of the Telnet option, which stops TN3270 mode (IAC DONT BINARY IAC WONT BINARY) and the NVT messages at disconnect time in CIPTN3270 server.
The workaround is to take down the DLUR-DLUS session. [CSCdj19817]
This problem only affects customers using TN3270E.
The buffers are lost only if BIND is followed immediately by unbind without SDT. This is small window of time, but some host applications might amplify it and should be avoided.
To keep the PU from locking if the TN3270E and special host application are being used periodically reload the CIP microcode. Although PU re-activation is also a way to recover, it does not guarantee recovery. [CSCdj20210]
A possible workaround is to ensure that the client always goes back to SSCP-LU after being in session, which means not using LOGAPPL or session-queuing. [CSCdj20596] 
May 27 18:26:37: %CIP1-1-MSG: %TN3270S-1-LU_ERROR: lu error lu not in hash
table: :36 pu:80A78998, tnet:0 May 27 18:26:37: %CIP1-1-MSG:
%TN3270S-1-LU_ERROR_INFO: LU info: Event 0 0 0 0 0 0 0 0 0 0 0 0 0 3 6 14 ,
state = A, snaState = 0, flag = May 27 18:26:37: %CIP1-1-MSG:  1
This error message is caused by fixing CSCdj15559. These error messages should not hurt network operations. [CSCdj21011] 
CCA-0-DEV_ERR2: Device error but no active defined device

The workaround is to determine and resolve the reason for the ESCON link error. [CSCdj21031]

CIP Microcode Release cip22 Caveats and Modifications

The following sections describe the caveats to current CIP microcode versions and the modifications made in current CIP microcode versions for cip22 microcode. The caveats listed apply to only the most serious problems. See Table 5 for the Cisco IOS software releases supported by cip22 microcode.

Caveats for Version 22.25/Version 22.26 Modifications

This section describes possibly unexpected behavior by Version 22.25. All the caveats listed in this section are resolved in Version 22.26. See Table 5 for the Cisco IOS release software version that corresponds to the 22.26 microcode version.

The workaround is to not use sysreq or to reconnect the client if a SSCP-LU session is required. [CSCdj21850]
The workaround is to properly configure the devices on the mainframe. The most likely cause of the problem is under the virtual machine (VM) if the write device is attached to the read subchannel. In this scenario, detach both devices (read and write) and reattach them to the correct subchannel. [CSCdj23802]
[CSCdj41342]
The workaround is to recycle the PU. [CSCdj46065]
The workaround is to recycle the TN3270. [CSCdj50517]
There is no workaround. [CSCdj51076]
This situation occurs with certain patterns of "good" and "bad" PUs. For example, out of a total of six PUs, the first five could be INACT at the host and the sixth could be CONCT.
The workaround is to shut down the PUs on the CIP or make them active at the Host. [CSCdj54138] 
Channel (F7)             Cisco/CIP        Explanation
 
   ALA    ==================>         (CH sends Aquire Link Address) 
          
          <=================   ALA    (CU sends Aquire Link Address) 
 
   ACK    =================>          (CH acknowledges request from CU) 
 
           End of Communication       (CU never acknowledges request from CH)

[CSCdj55448]
The workaround is to reconnect the client. [CSCdj58664]
The workaround is to reconnect the client. [CSCdj59985]

Caveats for Version 22.24/Version 22.25 Modifications

This section describes possibly unexpected behavior by Version 22.24. All the caveats listed in this section are resolved in Version 22.25. See Table 5 for the Cisco IOS release software version that corresponds to the 22.25 microcode version.

The workaround is to revert to a previous CIP microcode version or install the next release, which does not contain this problem. [CSCdj51725]

Caveats for Version 22.23/Version 22.24 Modifications

This section describes possibly unexpected behavior by Version 22.23. All the caveats listed in this section are resolved in Version 22.24. See Table 5 for the Cisco IOS release software version that corresponds to the 22.24 microcode version.

Caveats for Version 22.22/Version 22.23 Modifications

This section describes possibly unexpected behavior by Version 22.22. All the caveats listed in this section are resolved in Version 22.23. See Table 5 for the Cisco IOS release software version that corresponds to the 22.23 microcode version.

The workaround is to configure the CIP TN3270 PUs as connecting at the host. [CSCdj07152]
For the TN3270E client, there is no warning message if the host does not send a start data traffic (SDT) message. If a Telnet instead of a TN3270 client connects in the connection will fail, but an LU may be permanently assigned and not be reused again. If the host sends a DACTPU message, the statistics of the LU connections and disconnections may be wrong.
Some hosts may send system services control points (SSCP) LU data before they send notify-response data. Also, a "no bind" warning message may be sent. [CSCdj24694] 
Jul  4 00:10:28: %CIP25-6-MSG: %MSG802-6-LLC_DUP_SAP: LLC Duplicat SAP on interface 546 : SAP=4.
Issuing the llc show all command on the CIP indicates that CSNA has failed to clear up one remaining session. 
CIP-Slot5#llc show all
--- AdapNo 02, LanType Token     , SAP 04 ---
pcep=0860 rmac=4000.0000.7190 lmac=C000.0115.6500 rsap=04 lsap=04 this=8120EDA8
pcep=0860 state=ADM rbusy=no  lbusy=no  flow=on  pflag=1 dflag=0 v_r=0    v_s=0    last_nr=0    flag=60264282

The workaround is to issue a microcode reload command to clear the hanging session. [CSCdj26081] 
SSI_ASSERT failure in ../cta802/ccb802.c @ 3044 - LOOPBACK_FLOW_RECEIVED
Fatal error (code=09)
[CSCdj29175] 
 "%DEBUGGER-0-STACK_DATA8: 0000  FFFFFFFF 803F0010 00000000 00010001  ..."
If the second double word on this line contains 00000000 00010001 it is likely that the crash was caused by this bug. [CSCdj30387]
This bug is a regression caused by CSCdj28167. It occurs if the last message the host sends does not have end bracket (EB) bit on it. [CSCdj30937] 
Jul 30 00:53:29: %CIP3-3-MSG: %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../cta/cta.c @ 345 - FALSE
Jul 30 00:53:29: %CIP3-0-MSG: %DEBUGGER-0-FATAL_ERROR: Fatal error (code=09)
[CSCdj30949]
There is no guaranteed workaround other than to avoid random disconnection from the client in the middle of transactions. [CSCdj31131]
For example, the interface works well if it is brought up with 6000 sessions. However, when the interface is issued a shutdown and no shutdown command, an additional 64K 160-byte buffers is added to one of the CTA buffer pools, consuming about 10 MB of memory. This excessive memory consumption causes various problems depending on the size of the CIP memory. The size of the buffer pool can be corrected by issuing a micro reload command. [CSCdj31884]
The workaround is to issue the no csna command on the nonfunctioning subchannel, the no shutdown command on the physical interface, or the micro reload command. [CSCdj38712]
The workaround is to use PU names that are less than eight characters. [CSCdj39358]

Caveats for Version 22.21/Version 22.22 Modifications

This section describes possibly unexpected behavior by Version 22.21. All the caveats listed in this section are resolved in Version 22.22. See Table 5 for the Cisco IOS release software version that corresponds to the 22.22 microcode version.

 %CIP0-3-MSG: %SSI802-3-FATAL_ERROR: SSI_ASSERT failure in ../ssi/ssi_buff.c @ 158 - (msg) && ((( msg)->m_flags & ( M_PK
 %CIP0-3-MSG: THDR | M_EXT)) == ( M_PKTHDR | M_EXT))
[CSCdj23424]
The workaround is to handle multiple chain messages as if they are definite responses from the host while generating TN3270E header. This workaround will ensure that the definite-response from the host can be used to guarantee an end-to-end response. [CSCdj24073]
%CIP21-0-MSG: %CCA-0-BSQ_FULL: Buffer status queue is full
[CSCdj25040] 
%DEBUGGER-0-STACK_DATA8: 0000  FFFFFFFF BE810000 00000000 00000100  ...
If the second double word on this line contains 00000000 00000100 it is likely that the crash was caused by this bug. [CSCdj25062]
The workaround is to drop the duplicate request. [CSCdj31238]

Caveats for Version 22.20/Version 22.21 Modifications

This section describes possibly unexpected behavior by Version 22.20. All the caveats listed in this section are resolved in Version 22.21. See Table 5 for the Cisco IOS release software version that corresponds to the 22.21 microcode version.

%CIPn-2-MSG: %IPC-2-NOMEMD: Unable to obtain CBUS IPC transmit buffers(BUS)
This error message does not cause any problems to the network. [CSCdj00153] 
%DEBUGGER-0-FATAL_ERROR: Fatal error (code=32)
This failure has only been observed at sites running the CIP across an SRB network to a host (instead of the normal channel attachment). [CSCdj17365]
This malfunction could be caused by the following:

  • TN3270 clients not following the RFC which allow network virtual terminal (NVT) messages to be sent at disconnection time to inform the client of reason for disconnection.

  • the client TCPIP stack reorder the data and FIN (finish) packets causing an error on client

The workaround is to upgrade to a client TCPIP stack and application that conform to RFCs.
This error disables the capabilities of the Telnet option, which stops TN3270 mode (IAC DONT BINARY IAC WONT BINARY) and the NVT messages at disconnect time in CIPTN3270 server. [CSCdj19545]
The workaround is to take down the DLUR-DLUS session. [CSCdj19817]
A possible workaround is to ensure that the client always goes back to SSCP-LU after being in session, which means not using LOGAPPL or session-queuing. [CSCdj20596] 
May 27 18:26:37: %CIP1-1-MSG: %TN3270S-1-LU_ERROR: lu error lu not in hash
table: :36 pu:80A78998, tnet:0 May 27 18:26:37: %CIP1-1-MSG:
%TN3270S-1-LU_ERROR_INFO: LU info: Event 0 0 0 0 0 0 0 0 0 0 0 0 0 3 6 14 ,
state = A, snaState = 0, flag = May 27 18:26:37: %CIP1-1-MSG:  1
This error message is caused by fixing CSCdj15559. These error messages should not hurt network operations. [CSCdj21011] 
CCA-0-DEV_ERR2: Device error but no active defined device

The workaround is to determine and resolve the reason for the ESCON link error. [CSCdj21031]

Caveats for Version 22.19/Version 22.20 Modifications

This section describes possibly unexpected behavior by Version 22.19. All the caveats listed in this section are resolved in Version 22.20. See Table 5 for the Cisco IOS release software version that corresponds to the 22.20 microcode version.

With this fix, the CIP now specifically checks for a host descriptor and searches through the control blocks for a match. Because using the host descriptor is considered incorrect behavior, the following error message is displayed: 
OFFL-4-WRONGDESC
[CSCdi64196]
trace len 500
trace all off
trace offl on
trace offl_hdr on
trace socket on
stop offl_lpurge on
Wait for the next BADPURGE error message and capture the trace table information:
tasks
trace display
stop off
trace default
Then, send the output and all the console messages to Cisco engineering to resolve the problem. [CSCdi84662]
The workaround is to not configure more devices or subchannels on a Channel Interface than are designated in the router configuration manual. [CSCdi86777]
A workaround is to take down the DLUR-DLUS pipe after restoring the link. This can be done by issuing the VARY NET,INACT,ID=x,F command at VTAM, where x is the CP name of the DLUR, then making it active again. During this recycle, no new LU-LU sessions can be established, but existing sessions will be unaffected. [CSCdj09855]
The workaround is to correctly configure the PU. [CSCdj14302] 
%MSG802-6-LLC_DUP_CCB.
[CSCdj14957]

Caveats for Version 22.18/Version 22.19 Modifications

This section describes possibly unexpected behavior by Version 22.18. All the caveats listed in this section are resolved in Version 22.19. See Table 5 for the Cisco IOS release software version that corresponds to the 22.19 microcode version.

[CSCdj08881]

Caveats for Version 22.17/Version 22.18 Modifications

This section describes possibly unexpected behavior by Version 22.17. All the caveats listed in this section are resolved in Version 22.18. See Table 5 for the Cisco IOS release software version that corresponds to the 22.18 microcode version.

The workaround is to reload the CIP microcode. [CSCdi41087] 
tnet sequence lost, expected....
[CSCdi68249] 
IST1016I
REASON = LU HAS ACTIVE OR PENDING ACTIVE SESSIONS
The LU has a controlling Primary LU as defined by the LOGAPPL parameter.
The workaround is to request another session. [CSCdi86173]
The workaround is to ensure that the outbound data is not segmented and by configuring the llc2 N1 4105 command on the virtual adapter of the CIP virtual interface. [CSCdi91434]
The workaround is to reduce the offered load on the affected CIP card by reducing the number of connected sessions. [CSCdi92360] 
%TN3270S-1-NegRsp_NO_CORRELATOR: TN3270E Neg Resp no correlator found
This error message makes it impossible to isolate the cause of the problem. A useful error message includes the remote IP address and LU details. [CSCdj03345]
Now, for each CLAW statement, the CIP microcode will retain the static 64 buffers that are 4096 in size. However, each 4096 byte buffer can be segmented into either 4 smaller buffers of 1024 bytes each or 8 smaller buffers of 512 bytes each. When buffers are allocated in this fashion, the 4096-byte buffer is reassembled after all of the smaller chunks are freed. [CSCdj03799] 
TN3270S-1-LU_NO_BUFFER: No buffer for lu: SNA PosRspToHost.
[CSCdj05600]
If a CIP microcode reload does occur, then check to see if the CIP TN3270 server displayed the following message when the PU was configured: 
%CIP3: OpenNMLogListenEndPoint failed:bind failed
If this caveat occurs, then it is likely that the situation described in CSCdj07773 occurred previously and the user should not perform a shutdown.
The workaround is to reload the CIP microcode manually. [CSCdj07762]

Caveats for Version 22.16/Version 22.17 Modifications

This section describes possibly unexpected behavior by Version 22.15. All the caveats listed in this section are resolved in Version 22.17. See Table 5 for the Cisco IOS release software version that corresponds to the 22.17 microcode version.

This is a regression in the code Release 11.0(13.3)BT1(1.4) and 11.2(4.2) and was introduced by CSCdi90765.
The workaround is to not issue a no TN3270 or the no pu command within 10 seconds of a client disconnecting. [CSCdi93241]
To work around this problem, consult the documentation for mainframe applications. Some of the applications have startup modification options that can disable End Bracket and Change Direction PUs. [CSCdj00195]

Caveats for Version 22.15/Version 22.16 Modifications

The Version 22.16 was never released. All of the modifications listed in version 22.16 are included in Version 22.17.

Caveats for Version 22.14/Version 22.15 Modifications

This section describes possibly unexpected behavior by Version 22.14. All the caveats listed in this section are resolved in Version 22.15. See Table 5 for the Cisco IOS release software version that corresponds to the 22.15 microcode version.

This problem occurs under the following two possible failure scenarios:

  • The PCA-to-CIP communication will sometimes hang if the PCA adapter is configured with a path value that is not 0100 and no shutdown/shutdown interface commands are applied to the PCA interface. However, if a path value of 0100 and any other valid path value are defined on the PCA interface, the PCA-to-CIP communication will not hang.

If the 0100 PCA logical path is not going to the established state as displayed by the show extended channel slot | port stats command and the CHPID is online, the customer may encounter the PCA-to-CIP communication problem. The workaround is to issue a shut command on the interface, issue a microcode reload command, and then issue a no shut command.

  • The PCA-to-CIP communication might hang if a microcode reload is performed while the PCA interface is not shut down. This problem can also occur following a microcode reload command or no shut command if the 0100 PCA logical path is not going to the established state as displayed by the show extended channel slot | port stats command and the CHPID is online. After subsequent attempts to reload the microcode, the following messages indicate there is a PCA-to-CIP communication hang problem:

%CIP0-0-MSG: %ADAPTER-0-DIAGFAIL: Port 0 failed the PCA Diagnostic Mode 1 diagnostic
%CIP0-0-MSG: %ADAPTER-0-DIAGDATA: Module Call: 0 0 Error ID: 0 FFFFFFFF 0 c
The workaround is to use online insertion and removal to reset the CIP. There should be a 10-second delay between the removal and the insertion of the CIP card. [CSCdi77139] 
CIP5-0-MSG: %DMA-0-BADFIFO: FIFO failure detected during transfer (40 7E90).
[CSCdi79267]
The workaround to properly shut down a host, ESCON channel, link or PU is to shut down the PUs that will be affected before shutting down the host resource. [CSCdi81150]
The workaround is to keep active at least one PU on the IP/port, which prevents the statistics from being reset. [CSCdi82513]
View the output from the show extended channel slot | port tcp-stack and show extended channel slot | port udp-stack commands to view the errors. The variables that will be incremented for TCP and UDP will be TcpInErrors and UdpInErrors, respectively. [CSCdi83308] 
*Dec 30 14:54:21: %CIP0-3-MSG: %OFFL-3-ILLEN: Illegal byte count in offload data. 
 1599427375 specified, 20500 available.  xfer_element = 0
 
*Dec 30 14:54:21: %CIP0-3-MSG: x841BDA68
 
The FTP sessions, however, are unaffected at the application level.
[CSCdi83886] 





Route selection problems can occur in networks with user-defined parameters in the transmission group characteristics. [CSCdi84886]






%CBUS-3-INITERR: Interface 65535, Error (8034), idb 00000000 0 rx_setup - cbus_init()





[CSCdi85216]








The workaround is to use shorter LU and NETID names. [CSCdi90243]








If the customer has an operating system that includes CSCdi26192, but is using a microcode that does not include the fix for this DDTS, the following error messages will be displayed when issuing the show controller cbus command:





00:09:52: %CBUS-3-CCBCMDFAIL1: Controller 0, cmd (77 0x00000000) failed (0x8008)00:09:52: %CBUS-3-CCBCMDFAIL1: Controller 0, cmd (77 0x00000010) failed (0x8008)00:09:52: %CBUS-3-CCBCMDFAIL1: Controller 0, cmd (78 0x00000001) failed (0x8008)





[CSCdi90794]










The workaround is to use Dynamic Definition of Dependent LU (DDDLU)-enabled PUs. [CSCdi92154]






 Caveats for Version 22.12/Version 22.14 Modifications


 This section describes possibly unexpected behavior by Version 22.12. All the caveats listed in this section are resolved in Version 22.14. See Table 5 for the Cisco IOS release software version that corresponds to the 22.14 microcode version.



Step 1  Signs on (userid and password) to the session manager.


Step 2  Selects a Customer Information Control System (CICS) application. Clsdst/pass occurs to CICS application. Simlogon happens to session manager. 


Step 3  Enters a CICS transaction.


Step 4  Releases the session from a CICS master terminal. The Rumba V4.1 TN3270 client then returns the message "requested LU unavailable."  


Step 5  User disconnects from the Rumba client and reconnects, bypassing the entry validation screen. User is sent directly to the application selection menu.




The existing sequence is:





    Host              Tn3270            Client
           <--------------------------- logoff
    unbind ---------->
                       disc ---------->
           <--------- +r unbind
           <--------- Nfy Unav





This problem will be fixed in a future release. [CSCdi58780]








This problem is corrected by making sure the socket control block for a paused socket remains after the socket closes until the resume operation is processed. [CSCdi72208]








The workaround is to connect the downstream print clients before directing the host print software to queue sessions to the affected LUs. [CSCdi73134]








[CSCdi75996]








The memory leak is slow over a period of days when processing 4000 TN3270 connections per day. The workaround is to reload the CIP microcode periodically (for example, once a week). 



Inspect the output of show controller cbus daily and look at the amount of DRAM available to the CIP. [CSCdi76764]








If TN3270 printer sessions are not being run, this problem will not happen. This problem does not affect operation of TN3270 sessions or the TN3270 server itself. [CSCdi76786]






%CIP0-0-MSG: %ADAPTER-0-DIAGFAIL: Port 0 failed the PCA Diagnostic Mode 1 diagnostic
%CIP0-0-MSG: %ADAPTER-0-DIAGDATA: Module Call: 0 0  Error ID: 0 FFFFFFFF 0 c





The workaround is to OIR of the CIP with a 10-second delay between the removal and the insertion of the CIP card. [CSCdi77139]








If SNMP requests and show extended channel commands are not issued, there is no problem. [CSCdi77480]








IMS does not perform a read partition query to determine the terminal's screen size characteristics. If IMS receives a LOGMODE message with a primary screen size of 24 x 80 (MOD2) and an alternate screen size of 27x132 (MODS), IMS sets the bind to both primary and alternate screen size of 27x132 (MOD 5). TN3270 server does a +RSP to the bind, but the TN3270 client does not know that the primary screen size has changed. The client expects a primary screen size of MOD2, and the application (IMS) has changed the primary screen size to MOD5. 



When IMS sends an ERASE WRITE message, it expects the screen to be 27 x 132. The client expects the screen to be 24 x 80 and a garbled screen results.



This problem affects all non-TN3270E clients. Many TN3270E clients are also affected because they ignore the bind data. 



The TN3270 server must detect the discrepancy and translate between ERASE WRITE and ERASE WRITE ALTERNATE messages. [CSCdi77802]








The workaround is to recycle the PU using INACT,TYPE=REACT instead of INACT followed by ACT. [CSCdi79815]








Similarly, the user's logon will be sent in 3270DS format, and the host must be configured to expect that. If the USS10 sent was in the wrong format, the logon will not be understood. 



The CIP TN3270 server should detect the problem and do what it can to convert the datastreams. Users often do not realize they must configure the host to match the format. [CSCdi82008]






 Caveats for Version 22.10/Version 22.12 Modifications


 This section describes possibly unexpected behavior by Version 22.10. All the caveats listed in this section are resolved in Version 22.12. See Table 5 for the Cisco IOS release software version that corresponds to the 22.12 microcode version.



%CIP2-1-MSG: %TN3270S-1-NO_BIND_REQ_RCVD: No BIND REQ received on LU...





The LU affected is not disabled; a VTAM display of the LU shows that it is ENABLED.



Proper operation would allow the LU (printer or screen) to remain unbound until the inactivity timer triggers or the connection is shut down. In any case, proper operation dictates that a disconnected TN3270 session is reflected with the LU being in a DISABLED or INHIBITED state. [CSCdi70475]






%CTA-0-INACTIVE: PA0 CTA 0110-06 reset after being inactive for 180 seconds 





[CSCdi71177]








A workaround for this problem is to go to the DLUR configuration mode under the TN3270 Server configuration mode of the virtual interface and issue no lsap commands to deconfigure the adapter attachment points for DLUR before deactivating the TN3270 Server. Be sure to record the current link and lsap command contents, as these values must be reconfigured when the TN3270 Server is brought up again. [CSCdi71216]






PA1 CTA c010-d1 reset after being inactive for 180 seconds





[CSCdi73007]








Host applications that issues accept requests to the Offload devices can cause memory leaks of roughly 3 KB for every connection accepted. The Telnet Server application in MVS TCP/IP V3.1 is one example of such an application. Because of the memory leak, eventually the Offload application can no longer find enough memory to create new sockets and prints out the following error message:





%OFFL-3-REJSOCK: Not enough memory to handle new socket.  sockets open.





The TCPIP job log on the host will show the following error message:





EZB5141E Unexpected result from offload device ... ... 
EZB5153I        trgcls hi-order accept... 
EZB5162I     Data: 
EZB5062I 000000:00000001 FFFFFFFF FFFFFFFF 0000000C





This message indicates that the application on the host will no longer accept any incoming connections on that socket. For the Telnet Server, TCPIP must be recycled to allow clients to connect to the host again. Recycle other applications to correct the problem on the host.



To correct the problem on the CIP, the Offload device must be unconfigured and reconfigured or the channel interface must be bounced (shut down and then restarted) with a shut command followed by a no shut command.



The only workaround is to occasionally bounce the Offload devices on the CIP. [CSCdi74628]







 Caveats for Version 22.7/Version 22.10 Modifications


 This section describes possibly unexpected behavior by Version 22.7. All the caveats listed in this section are resolved in Version 22.10. See Table 5 for the Cisco IOS Release Software Version that corresponds to the 22.10 microcode version.





The more static LUs in the network, the higher the chance that any given LU is affected. [CSCdi67583]








For Release 11.0(11):



    

  • cip21-10 for CIP 1
    

  • cipp21-10 for CIP 2
    



For Release 11.1(6):



    

  • cip22-10 for CIP 1
    

  • cipp22-10 for CIP 2
    



There is a potentially catastrophic problem with the CSNA feature in the microcode bundled with Cisco IOS Release11.0(11). The problem can occur with SNA path information units (PIUs) 4025 bytes or larger destined for the channel. [CSCdi69773]






 Caveats for Version 22.6/Version 22.7 Modifications


 This section describes possibly unexpected behavior by Version 22.6. All the caveats listed in this section are resolved in Version 22.7. See Table 5 for the Cisco IOS Release Software Version that corresponds to the 22.7 microcode version.



DMA-0-BADFIFO: FIFO failure detected during transfer (4x 0100) 
DMA-0-BADFIFO: FIFO failure detected during transfer (4x 0001)





The numbers 0100 or 0001 in the parentheses indicate that the error is from a different type of unexpected behavior. IP datagram connections will drop packets that encounter the DMA transfer problem. Only packets coming from the mainframe are affected. These dropped packets will be retransmitted by higher level protocols (for example, TCP) and the new packets will not run into the same problem due to different IP sequence numbers in the IP header.



Offload connections will drop outgoing packets (packets from the mainframe) that encounter the DMA transfer problem. Incoming packets will be dropped due to incorrect TCP or UDP checksums. Again, higher-level protocols will retransmit the packet. CSNA will be affected in much the same way as IP datagram. The major difference is that there is nothing equivalent to an IP sequence number in an LLC2 packet, so the retransmitted packets could encounter the DMA transfer problem. If enough unsuccessful retransmissions occur, the LLC2 session will drop. However, it is unlikely that this problem will occur because there are numerous conditions that must be met. [CSCdi54732]






%CIP5-3-MSG: %CONFIG-3-WRONGINT: VCN 0(0000) not for port adapter 2





In addition to preventing the unexpected halt, the fix in version 22.7 also adds code to print out the beginning of the bad packet. This allows to find out why the VCN was wrong. [CSCdi61532]






CLAW-6-TOOBIG: 4352 byte IP datagram exceeds CLAW MTU for device 





The workaround is to reload the router. [CSCdi64874]







 Caveats for Version 22.3/Version 22.6 Modifications


 This section describes possibly unexpected behavior by Version 22.3. All the caveats listed in this section are resolved in Version 22.5. See Table 5 for the Cisco IOS Release Software Version that corresponds to the 22.6 microcode version.



INOP RECEIVED FOR XXXXXXXX code = 02 





[CSCdi64229]







 Caveats for Version 22.0/Version 22.3 Modifications


 This section describes possibly unexpected behavior by Version 22.0. All the caveats listed in this section are resolved in Version 22.3. See Table 5 for the Cisco IOS Release Software Version that corresponds to the 22.3 microcode version.




 CIP Microcode Release cip21 Caveats and Modifications


 Because CIP Microcode Version 22.0 was based on Version 21.3, modifications made in Version 21.3 are listed in this section.



 Caveats for Version 21.3/Version 22.0 Modifications


 CIP Microcode Version 22.0 was the first version specifically built for unbundled microcode support under Cisco IOS Release 11.1. See Table 5 for the Cisco IOS release software version that corresponds to the 22.0 microcode version.



 Modifications


 CIP Microcode Version 21.3 fixed the following:





The router will show that the Claw connection, as viewed by show extended channel slot/port statistics is connected, but the static route will be removed. [CSCdi45752]








The subroutine that handles the reconnect logic requires this fix. [CSCdi47267]






 CIP-Related Caveats for Cisco IOS Releases


 For a complete list of caveats against the Cisco IOS Releasees, use Cisco Connection Documentation or access Cisco Connection Online as described in the section "Cisco Connection Online" later in this document. You can also refer to the following publications which are available on Cisco Connection Documentation:




 CIP and Processor Module ROM Monitor Recommendations


 CIP and processor module (RP, RSP, and RSP7000) ROM monitor (system bootstrap) versions and system software images are typically independent of each other; however, the CIP hardware version does have minimum recommended requirements in terms of Cisco IOS Release and CIP Microcode Version as listed in Table 5. Other microcode versions can be used, but only when specifically instructed to do so by technical support personnel. Table 5 identifies the processor module monitor versions. 



Note For Cisco IOS Release 11.2 BC, the CIP card is supported only on the Cisco 7000 with RSP7000 and the Cisco 7500 series routers. 



 Use the show diag EXEC command to display the CIP hardware version. The original CIP card is identified as version 4.x. The CIP2 card is identified as version 5.x.




Table 6: CIP Hardware, Cisco IOS Release, and CIP Microcode Compatability 

CIP Hardware Version
Minimum Cisco IOS Release Required
Minimum CIP Microcode Version Recommended 

 CIP 4.1
 10.2(4.6) 
 cip10-4

 CIP 4.2

 10.3(5.1)
 cip10-7

 10.3(8.5)
 cip20-5

 10.3(6.2)
 rsp_cip20-2

 CIP 4.41

 20.2(10.2) or later
 cip10-4

 
 cip20-4

 10.3(7.5)
 cip10-9

 10.3(8.5)
 cip20-5

 10.3(7.5)
 rsp_cip20-3

 11.0(3.5)2
 cip11-4

 11.0(4.5), 11.1(1)
 cip21-3

 11.0(3.5)
 rsp_cip21-2

 11.1 any version
 cip22-x

 11.2 any version
 cip22-x

 111CIP2 5.x

 10.2(3), 10.3(13)
 cipp20-8

 11.0(10)
 cipp21-7

 11.1(5)
 cip22-6

 11.1(6)
 cip22-7

 11.1(7), 11.2(1), 11.2(2)
 cip22-10

 11.1(8), 11.2(3), 11.2(4)
 cip22-12

 11.1(9)
 cip22-14

 11.1(10)
 cip22-15

 11.2(5)
 cip22-17

 11.1(11)
 cip22-18

 11.2(6)
 cip22-19

 11.1(12), 11.2(7)
 cip22-20

 11.1(13), 11.2(8)
 cip22-21

 11.1(14), 11.2(9)
 cip22-22

 11.1(15)
 cip22-23

 11.2(10), 11.1(16)
 cip22-25

 11.2(11), 11.1(17)
 cip22-26

 11.2(8)BC
 cip24-0

 11.2(9)BC
 cip24-1

 11.2(10)BC
 cip24-2

 11.2(11)BC
 cip24-3

 11.3(1)
 cip25-3






1 
The Cisco 7500 series requires CIP hardware revision 4.4 or later.


2 
 Cisco IOS Release 11.0 and later also requires a CIP hardware revision 4.4 or later.




 Table  7: Minimum Recommended CIP Boot ROM Versions

Platform and Processor
CIP Boot ROM Version
Processor ROM Monitor Version

 Cisco 7000 family router1 with a Route Processor (RP), 7000 Series Route Switch Processor (RSP7000), RSP1, and RSP2
 Version 1.6 or later (required)
 System Bootstrap Version 11.0 or later






1 
The Cisco 7000 family routers include the Cisco 7000, Cisco 7010, Cisco 7505, Cisco 7507, and Cisco 7513.




 CIP and RP/RSP DRAM Requirements


 For the Cisco routers to take advantage of the Cisco IOS Release Software CIP features, you might need to upgrade code, main system, or CIP memory. For specific Cisco IOS-related memory requirements, refer to the Release Notes for Cisco IOS Release 11.x publication, which is available on Cisco Connection Online.



 CIP Microcode Upgrade Overview


 Following is an overview of how to upgrade unbundled CIP microcode (CIP Microcode Version 22.0 and later) for the Cisco 7000 family routers. 



Note In the following procedure, a Cisco IOS Release 11.1 (or later) image is booted before the CIP microcode image is copied to Flash memory.



 For CIP microcode images that were shipped on floppy disks or were obtained from CCO, do the following:


Step 1  Upload the CIP microcode image (and the Cisco IOS image if not on ROM) from the floppy disks or from CCO to a TFTP server.


Step 2  From the running configuration, remove any microcode cip configuration commands that specify a CIP microcode image.


Step 3  Save your running configuration to a TFTP server or Flash memory.



Note If you have a Cisco 7000 series router and plan to install new software ROM with Cisco IOS software, skip Steps 4 and 5 and turn off power to your router. Install the new ROMs, then proceed to Step 6.



Step 4  Before you copy tftp you need to rename the microcode you downloaded from CIP22-3.TAR to CIP22-3. If you do not rename the microcode image, the RSP does not find the kernel because it will be named CIP22-3.TAR_kernel...  instead of CIP22-3_kernel....


Step 5  Download the Cisco IOS Release software image to Flash memory.


Step 6  Configure the router to boot from the Flash memory where the Cisco IOS Release software image resides.


Step 7  Boot the Cisco IOS Release software image.



Note The router must be running Cisco IOS Release software before copying the CIP image to Flash memory in the following step because the CIP image must be "exploded" from the single image file on the TFTP server to multiple files in Flash memory. This capability is added in Release 11.1.



Step 8  Download the CIP microcode image to the Flash memory card in slot 0.


Step 9  Perform a microcode reload.


Step 10  Restore the running configuration with the configuration you saved to the TFTP server in Step 3.


 For CIP microcode that shipped on Flash memory cards, do the following: 


Step 1  Insert the Flash memory card into a Flash memory card slot 0.


Step 2  Configure the router to boot from the Flash memory card in slot 0. 



Note For the specific procedures associated with the steps in this overview, refer to the companion publication Upgrading Software and Microcode in Cisco 7000 Family Routers (document number 78-1144-xx), which includes the information and procedures necessary to upgrade your CIP microcode. The Upgrading Software and Microcode in Cisco 7000 Family Routers publication includes information on upgrading software and microcode images, transferring files to and from Trivial File Transfer Protocol (TFTP) servers, copying files between nonvolatile random-access memory (NVRAM) and Flash memory, and between TFTP servers and Flash memory. The publication also includes basic instructions for booting your system.




 Cisco Connection Online


 Cisco Connection Online (CCO) is Cisco Systems' primary, real-time support channel. Maintenance customers and partners can self-register on CCO to obtain additional information and services.


 Available 24 hours a day, 7 days a week, CCO provides a wealth of standard and value-added services to Cisco's customers and business partners. CCO services include product information, product documentation, software updates, release notes, technical tips, the Bug Navigator, configuration notes, brochures, descriptions of service offerings, and download access to public and authorized files.


 CCO serves a wide variety of users through two interfaces that are updated and enhanced simultaneously--a character-based version and a multimedia version that resides on the World Wide Web (WWW). The character-based CCO supports Zmodem, Kermit, Xmodem, FTP, and Internet e-mail, and is excellent for quick access to information over lower bandwidths. The WWW version of CCO provides richly formatted documents with photographs, figures, graphics, and video, as well as hyperlinks to related information.


 You can access CCO in the following ways:



 For a copy of CCO's Frequently Asked Questions (FAQ), contact cco-help@cisco.com. For additional information, contact cco-team@cisco.com.



Note If you are a network administrator and need personal technical assistance with a Cisco product that is under warranty or covered by a maintenance contract, contact Cisco's Technical Assistance Center (TAC) at 800 553-2447, 408 526-7209, or tac@cisco.com. To obtain general information about Cisco Systems, Cisco products, or upgrades, contact 800 553-6387, 408 526-7208, or cs-rep@cisco.com.




 Cisco Documentation CD-ROM


 Cisco documentation and additional literature are available in a CD-ROM package, which ships with your product. The Documentation CD-ROM, a member of the Cisco Connection Family, is updated monthly. Therefore, it might be more up to date than printed documentation. To order additional copies of the Documentation CD-ROM, contact your local sales representative or call customer service. The CD-ROM package is available as a single package or as an annual subscription. You can also access Cisco documentation on the World Wide Web at http://www.cisco.com, http://www-china.cisco.com, or http://www-europe.cisco.com.


 If you are reading Cisco product documentation on the World Wide Web, you can submit comments electronically. Click Feedback in the toolbar, select Documentation, and click Enter the feedback form. After you complete the form, click Submit to send it to Cisco. We appreciate your comments.


 



 
















hometocprevnextglossaryfeedbacksearchhelp




Copyright 1989-1997 
 © 
Cisco Systems Inc.