Channel Interface Processor (CIP) Microcode Release Note and Microcode Upgrade Requirements

Table 1 : Cisco IOS Releases and CIP Microcode Releases for the Cisco 7000 Family

Cisco IOS Release	Default CIP Microcode Version	Minimum CIP Microcode Version Required
11.1(1)	22.0 (slot0:cip22-0)	22.0
11.1(2)	22.0 (slot0:cip22-0)	22.0
11.1(3)	22.0 (slot0:cip22-3)	22.3
11.1(4)	22.0 (slot0:cip22-3)	22.3
11.1(5)	22.0 (slot0:cip22-6)	22.6
11.1(6)	22.0 (slot0:cip22-7)	22.7
11.1(7)	22.0 (slot0:cip22-10)	22.10

CIP Microcode Caveats and Modifications

The following sections describe the caveats to current CIP microcode versions and the modifications made in current CIP microcode versions. The caveats listed apply to only the most serious problems.

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. Microcode versions 22.8 and 22.9 were not released for Cisco IOS 11.1.

• Historically, both the default and maximum values for the tn3270 server "maximum-lus" parameter were set at 20000. Due to licensing issues, the default value will be set to 2100; the maximum value will become 32000. License reminders will be displayed when the default is exceeded, and warning messages displayed when the configured maximum is approached. [CSCdi62250]
  

• Under some circumstances, static TN3270 LUs cannot be selected by name by the client. The LU is active at the Host and at the CIP but attempts to select it are refused as though it were unknown.
  

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

• For CIP CSNA users who are running IOS version 11.0(11) and 11.1(6), you should download one or both of the following microcode images from CCO.
  

For 11.0(11):

cip21-10 for CIP 1

cipp21-10 for CIP 2

For 11.1(6):

cip22-10 for CIP 1

cipp22-10 for CIP 2

There is a potentially catestrophic problem with the CSNA feature in the microcode bundled with IOS verion 11.0(11). The problem can occur with SNA PIUs 4025 bytes or greater 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.

• The CSNA failed to detect the HOST halted via the "ZET NET,CANCEL" command. This fix also speeds up the connection termination process so it will be more responsive to the vary active XCA major node command. [CSCdi53187]
  

• This bug is caused by the DMA controller on the CIP which transfers packets between MEMD (on the SP or RSP) and memory on the CIP. The resulting error message looks like this:
  

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

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

If the 4 digit number in parentheses is not 0100 or 0001, then it is a different bug. IP datagram connections will drop packets which encounter this bug. Only packets coming from the mainframe are affected. These dropped packets will be retransmitted by higher level protocols (e.g. 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 (i.e. packets from the mainframe) which encounter this bug. 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 very 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 in theory the retransmitted packets could hit the same problem. If enough unsuccessful retransmissions occur, the LLC2 session would drop. However, we have never seen this happening because there are enough other conditions which have to be met to cause the problem. [CSCdi54732]

• If the router switches a packet to the CIP for the virtual port adapter (i.e. interface channel <slot>/2) using the wrong virtual circuit number the CIP crashes. Before the fatal error dump you will see this error message:
  

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

In addition to preventing the crash, the fix also adds code to print out the beginning of the bad packet. This will allow us to find out why the VCN was wrong. [CSCdi61532]

• On a CIP 2 (hardware revision 5.x) with CSNA and TCP Offload both in use, TCP sessions could drop out randomly with the remote client appearing to have requested disconnect. [CSCdi63044]
  

• On a rare occasion if CIP gets a packet greater than 4k from RP/RSP, CIP may stop functioning properly and eventually may crash with fatal errors. The following message CLAW-6-TOOBIG: 4352 byte IP datagram exceeds CLAW MTU for device is an indication that the problem is being hit. Workaround is to reload the router. [CSCdi64874]
  

• If running IP datagram and a number of Selective Resets are issued to a CLAW connection, that CLAW connection may eventually hang. One sign that this is occurring would be if the CLAW connection state is "Y", but every packet from the router to the CIP is dropped as viewed by the Read Block Dropped counter in "sh ext chan <slot>/<port> stat". A microcode reload is required to clear the problem. [CSCdi65099]
  

• Whenever more the one device is configured on a CIP interface, a potential exists for those devices to stop accepting data from the mainframe. For claw type devices, this only prevents data from being received from the host. For CSNA type devices, this would prevent traffic from flowing into or out of the host. A microcode reload is required to recover from the problem. [CSCdi66108]
  

• CSNA and Offload are not supported features if the CIP hardware revision is lower than 4.4. This fix adds a warning if these features are configured on down level hardware. [CSCdi66745]
  

• When using a version of CIP microcode that contains the fix for CSCdi56069 (cip20-9, cipp20-9, cip204-80, cipp204-80, cip206-70) and running in an RASP platform, DBUS-INTERRs could result while entering commands into the CIP console. [CSCdi67549]
  

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. There was no released microcode Version 22.4 or 22.5.

• This fix address a CSNA problem. While in the process of bringing up a session or in data transfer phases, VTAM deactivates all active sessions with following error message: INOP RECEIVED FOR XXXXXXXX code = 02 [CSCdi64229]
  

• The CIP was designed to run two channel adapters with only 2MB of DRAM when running IP Datagram mode. When customers ran 32 CLAW devices with RIP, packets would be dropped even though additional DRAM was available to buffer packets until the mainframe could receive them. This change allows CIPs with more than 2MB of DRAM to make use of the additional memory when running IP Datagram mode. [CSCdi54042]
  

• This fix addresses unexpected behavior when running CSNA, which could potentially cause session failure, BADFIFO error messages, and other side effects. [CSCdi61131]
  

• Under certain conditions the File Transfer Protocol (FTP) server on VM or MVS stops functioning if the offload device returns an invalid return code to a particular socket request to receive data. This return code also generates a traceback in the TCPIP logs for TCPIP for VM and MVS. The offload device no longer returns this invalid return code. [CSCdi61870]
  

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.

• Hub terminals manufactured by HOB expect a Receive Ready (RR) to be sent after the SABME is sent. This is not required by the 802.2 standard. After the HOB sends a SABME to the CIP LLC stack, the CIP LLC stack should respond with an RR and then assume that the terminal is in normal transfer mode. [CSCdi45083]
  

• The Offload read and write tasks are created with too little stack space. Under certain conditions, typically when several hundred sessions are established, a stack overflow can occur, which usually leads to a fatal error dump. The error code in this dump can be almost anything, with 32 and 35 being most likely. If you are running Offload with microcode versions cip21-3, cip11-4, cip22-1, or earlier, you should upgrade to at least cip21-4 (Cisco IOS Release 11.0(7) or later) or cip22-3 (Cisco IOS Release 11.1(2.4) or later). [CSCdi48357]
  

• When running CSNA, during large bursts of LLC, type 1 traffic from VTAM (many sessions configured for callout) an automatic reload of the CIP microcode may occur with the following message displayed: SSI_ASSERT failure in../cta/cta_mbuf.c @ 287 ... [CSCdi48855]
  

• When running MVS V=R in a VM/XA guest machine with a PCA, the mainframe channel will generate an interface disconnect in the middle of command chaining when it reaches an invalid CCW. If multiple devices are active on the PCA, this may result in an SCB_CHAIN error. The only work around for the SCB_CHAIN error is not to run in this configuration. [CSCdi49057]
  

• When running CSNA, if XCA major nodes are cycled inactive/active many times without reloading the CIP microcode, a CCA error message TOOMANY may be seen, and channel operation is paused without completing the current channel program. Depending on traffic levels, operation may or may not resume. If not, the CIP microcode must be reloaded. [CSCdi51452]
  

• Restarting TCPIP on the mainframe while data is moving through an Offload connection can cause the CIP to halt unexpectedly. The result is a fatal error dump. This dump must be sent to development engineering for analysis. The problem can be avoided by shutting down TCPIP, which causes all open sockets/connections to be closed, before restarting it. [CSCdi51859]
  

• With the CSNA feature, if an XCA major node is inactivated or VTAM is shut down while connections are active and traffic is flowing to VTAM, the CIP may pause indefinitely. If this pause occurs, the CIP microcode must be reloaded. [CSCdi53138]
  

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. Because CIP Microcode Version 22.0 was based on Version 21.3, modifications made in Version 21.3 are listed below.

Modifications

CIP Microcode Version 21.3 fixed the following:

• This fix handles the VTAM flow request and eliminates the following message from being displayed: CSNA code does not recognize 0x0d50, Flow Request from VTAM [CSCdi45035]
  

• If the host sends a CLAW disconnect message to a link that has already been disconnected and that CLAW connection has a different link that is connected, the CIP will cause the static route for the CLAW connection to be removed. Older version of Interlink (2.1) and IBM TCPIP V2 behave in this manner.
  

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]

• When status is pending on initial connection, the pending status is not flushed. This resulted in owed status being suppressed. On CSNA connections this causes data transfer to stop, and VTAM or the Missing Interrupt Handler detects an operation as taking too long. [CSCdi46037]
  

• This fix only applies to CSNA users who are using host backup configuration. If the user has duplicate VTAMs, for backup purposes, the user can configure two or more logical LAN adaptors (ADAPNO) with same MAC address on different internal LANs. When one of the VTAMs is brought down, similar to varying off the XCA major node, or one of the VTAMs is in trouble, all end-stations that previously connected to the problem VTAM can then reconnect to the backup VTAM.
  

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

CIP-Related Caveats for Cisco IOS Release 11.1(7)

For a complete list of caveats against Cisco IOS Release 11.1(7), 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 Release Notes for Cisco IOS Release 11.1 publication (Document Number 78-2886-xx), which is 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 2. Other microcode versions can be used, but only when specifically instructed to do so by technical support personnel. Table 3 identifies the processor module monitor versions.

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 2 : CIP Hardware, Cisco IOS, and CIP Microcode Compatibility

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) 10.3(8.5) 10.3(6.2)	cip10-7 cip20-5 rsp_cip20-2
CIP 4.41	10.2(10.2) or later	cip10-4 cip20-4
	10.3(7.5) 10.3(8.5) 10.3(7.5)	cip10-9 cip20-5 rsp_cip20-3
	11.0(3.5) 11.0(4.5) 11.0(3.5)	cip11-4 cip21-3 rsp_cip21-2
	11.1 any version	cip12-x cip22-x rsp_cip22-x
CIP2 5.x	10.2(13), 10.3(13)	cipp20-8
	11.0(10)	cipp21-7
	11.1(5)	cip22-6
	11.1(6)	cip22-7
	11.1(7)	cip22-10

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

Table 3 : 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

¹ 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 11.1 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.1 publication (Document Number 78-2886-xx), 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.