IBM CIP Protocols

Document ID: 17556

Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
CSNA Channel Connection
      Channel Interface Processor
      XCA Major Node
      VTAM Switched Major Node
      CSNA Virtual LANs and the Switched Major Node PU TEST and XID Exchange
Host and Router Configuration Dependencies
      Cisco Systems Network Architecture
      CSNA Command Field
      Device Address Formulas
      Keywords
      CIP Internal LAN Configuration for CSNA and CMPC
Procedures to Troubleshoot CSNA
      Troubleshoot the Router
      Troubleshoot the Host
Common CSNA Problems
      End station gets no response to test poll.
      End station gets no response to NULL/IEEE XID.
      End station gets no response to XID0 or XID3.
      VTAM to PU4 or VTAM to VTAM through CSNA fails to connect.
      CSNA sessions drop when things get busy.
      The end station nth user can not get the CSNA connection.
      End user indicates invalid frame received from VTAM and tears down the session.
      Everything is fine through XID exchange, including PU and LU activation, but the user never sees the VTAM splash screen.
      Connection problem in duplicate MAC address environment.
      SDLLC connection that uses RSRB or DLSw+ is not coming up when switched to CSNA from FEP 3745.
      7000-CIP, FEP 3745, and SAA Gateway are all connected to the same token ring. No connection between SAA Gateway to VTAM when switched to CSNA from FEP 3745.
      Unable to bring up APPC Networking Services for Windows (NS/WIN) and the IBM PC/3270 for Windows (PC/3270) at the same time in a LAN environment. When both start at the same time, whichever program starts first works fine, but the other program hangs.
MSG802-6-BADNS_WARN Messages and How to Tune the LLC2 Window
NetPro Discussion Forums - Featured Conversations
Related Information

Introduction

This document introduces and describes the dependencies between the host and router Cisco Systems Network Architecture (CSNA) configuration macros and operands. It also provides a step-by-step troubleshooting guide to verify the CSNA connectivity. You can either read the next sections to gain an understanding of CSNA relationships or go directly to the Procedures to Troubleshoot CSNA section.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on these software and hardware versions:

• Channel Interface Processor (CIP) hardware version 5.0 and all versions of CIP Microcode

• Cisco IOS® Software 11.1 and later

• All versions of the host Multiple Virtual Storage (MVS) operating system

• Virtual Telecommunications Access Method (VTAM) version 3.4 or later

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

CSNA Channel Connection

CSNA provides support for traditional SNA channel connections between remote SNA end stations and channel-attached SNA mainframes. You can also run an Advanced Peer-to-Peer Networking (APPN) connection or High Performance Routing over CSNA.

The next four sections contain overview information about the major components of CSNA.

Channel Interface Processor

Cisco’s CIP is the channel-attachment interface for Cisco 7000 routers, and Cisco’s Channel Port Adapter (CPA) is the channel-attachment interface for the 7200 router. The CIP is used to connect a host mainframe to a control unit, which eliminates the need for a front-end processor (FEP) for channel attachment. The Cisco CIP communicates with remote SNA nodes through the use of CIP internal LANs called virtual rings, pseudo-rings, adapters, or MAC addresses. These LANs are configured on the CIP virtual interface slot/2 and, on the host, as external communication adapter (XCA) major nodes. The internal CIP adapters emulate the LAN adapters in the IBM 3172 interconnect controller. For new installations, the information in the Input/Output Configuration Data Set (IOCDS), the Input/Output Control Program (IOCP), or the Hardware Configuration Definition (HCD) configuration for the CIP should be identical to the information for a channel-attached IBM 3172. Therefore, you do not need to change the host definitions when you install the CIP card.

When a communications adapter is configured in the IBM 3172, the adapter is assigned a Relative Adapter Number (RAN) from 0 through 127, based on the adapter type and the order in which the adapter was configured. For example, if a 3172 has three token-ring adapters and one Ethernet adapter configured, its configuration shows three token-ring adapters with RAN 0, 1, and 2 and one Ethernet adapter with RAN 0. The 3172 RAN is not a slot number, and it is assigned by the 3172 configuration software. You have no direct control over RAN assignment.

The CIP does not require a rigid association between RANs and physical communications adapters. To maintain compatibility with the 3172 and the VTAM configuration, however the CIP uses the concept of internal LANs and internal adapters—no changes to the host are required when a 3172 is replaced with a CIP card. Internal LANs are also called virtual LANs or pseudo-LANs. Additionally, the CIP SNA feature allows the customer to have direct control over RAN assignments to the CIP internal adapters. CSNA provides connectivity through the use of MAC addresses configured on the internal adapters. These internal adapters correspond to XCA major node definitions in VTAM and provide access points (LAN gateways) to VTAM for SNA network nodes. Each CIP card can be configured with up to thirty-two internal LANs. Only token-ring format is supported on the CIP for the internal LANs. The Ethernet and Fiber Distributed Data Interface (FDDI) LAN support in the 3172 has not been implemented. Up to thirty-two internal adapters can be configured on a CIP.

XCA Major Node

CIP is transparent to VTAM because it is not addressable. It is not a physical unit (PU) like an IBM 3745, an IBM 3756, or an IBM 3174.

The CIP internal adapter (ADAPTER#) must match the ADAPNO configured in the corresponding VTAM XCA major node definition. In cases where a 3172 or 3745 is to be replaced by a CIP-equipped 7000 router, the MAC address of the 3172 adapter or the 3745 token-ring interface coupler (TIC) can be reused for the configured internal adapter. This allows SNA nodes in the network to continue to access the host with the same destination MAC addresses, after the CIP has been installed. The CIP internal adapter supports duplicate MAC addresses; each must be on a different internal LAN and each must have a different RAN.

Cisco routers and the remote SNA nodes are configured as if they are communicating with a real FEP or 3172 through standard protocols such as source-route bridging (SRB), data-link switching (DLSw), and so forth. You must use the assigned RANs (in case of CIP, the adapter numbers) to complete the configuration of VTAM XCA major nodes. An XCA major node is used to control the activation and deactivation of subchannels and service access points (SAPs) and their association with the CIP adapters.

The XCA major node represents the adapter on a CIP, usually a token-ring adapter with an assigned adapter number. For example, XCA ADAPNO=0, SAP=04 represents the CIP virtual token-ring adapter 0. CIP assumes the link service access point (LSAP) from the XCA major node 04. If the adapter number does not match the CIP, the XCA activation fails. Issue the DISPLAY command on the host (D net, id=JEXCA,e where JEXCA is the name of the XCA major node) or issue the CIP show extended channel slot/0 stat command to display the status of the LAN adapters. Ensure that, on VTAM, the XCA DESIRED STATE=ACTIV and, on the CIP, CON=Y.

XCA major nodes can use the same subchannel address, but they must have different SAPs or LANs. It is recommended that you use different XCA and CSNA subchannel addresses to separate the different CSNA connections from each other and from the TN3270 traffic, for easier troubleshooting.

VTAM Switched Major Node

The CIP SNA implementation supports standard switched major node (SMN) configurations. No special configuration parameters or procedures are necessary in VTAM for communication with the channel-attached 7000 router.

SNA views PU token-ring connectivity—through the IBM Gateway Communication Controllers (IBM 3745 or IBM 3172) or through the CIP card—as switched or dialed connections defined in a VTAM SMN. The remote PUs are configured on the host as the SNA SMN PUs; they represent the remote SNA controllers such as a 3174, a PC running 3270 or Advanced Program-to-Program Communication (APPC) emulation packages, or PUs configured on the CIP TN3270 Server.

The logical units (LUs) configured under the host SNA SMN PUs represent the remote LUs that reside on the remote PUs. The remote LUs manage the remote SNA devices such as 3270 terminals (LU type 2), printers (LU type 1 and 3), or the APPC distributed transaction programs (LU type 6.2).

CSNA Virtual LANs and the Switched Major Node PU TEST and XID Exchange

The next diagrams illustrate the flows in the TEST and exchange identification (XID) for the XCA and SMNs:

The remote PU—such as a PC, a 3174, a TN3270 Server, or a downstream PU (DSPU)—sends an explorer TEST to the CIP virtual MAC address 4000.4040.0000, remote SAP (RSAP) 04, which is the CIP XCA major node local SAP. After the TEST response is received from the CIP, the XID negotiation takes place with the host. In this example, the CIP simply passes the XIDs transparently to VTAM.

The XID contains the unique PU identifier which can be either IDBLK, IDNUM, or the APPN PU 2.1 control point (CP) name. If either the IDBLK, IDNUM, or APPN PU 2.1 CP name matches the values configured in the VTAM SNA SMN PU, the XID negotiation succeeds. Then, the Logical Link Control, type 2 (LLC2) connection is started with a set asynchronous balanced mode extended (SABME) and unnumbered acknowledgement (UA) exchange, as shown in the previous diagram. If the IDBLK, IDNUM, or APPN PU 2.1 CP name configured on the host in the SMN PU definitions (as well as on the remote PU) does not match the values in the SMN, the XID negotiation and the host PU activation fails, unless the host has been configured to dynamically create PU definitions. Issue the host DISPLAY command (D NET,ID=JESMN,E) to show the status of the host SMN named JESMN.

Host and Router Configuration Dependencies

The example configurations, diagrams, and notes in this section illustrate the relationships between the IOCP, the XCA major node, and the CIP router definitions.

The next diagram uses this VTAM XCA major node configuration:

VTAM XCA MAJOR NODE
ADAPTNO=0, CUADDR=7E4, SAP=04

!--- See #1 in the next diagram.

It also uses these macro definitions:

RESOURCE part = ((lpar1,1), (lpar2,2),(lpar3,3))

CHPID path=2C, type=cnc, shared, part=(lpar1,lpar2), switch=03)

!--- See #2 and #4 in the next diagram.

CNTLUNIT cunumbr=350, path=2C, unit=sctc, link=D0, unitadd=(E0,16), cuadd=0

IODEVICE address=(7E0,16), cunumbr=350, unit=sctc, unitadd=E0

This configuration has these setting:

• ESCON host port = C0 (see #3 in the next diagram).

• LPAR = 1 (see #2 in the next diagram and the RESOURCE and CHPID macros).

• Control Unit (CU) logical address = 0 (see #7 in the next diagram and the CNTLUNIT macro).

Therefore, the complete path is C010.

The device address [#9 in the next diagram] = ( CUADDR [from the VTAM XCA major node] – IODEVICE address [from the IODEVICE macro] ) + unitadd [from the CNTLUNIT macro] = ( 7E4 – 7E0 ) + E0 = E4

Thus, the complete path plus the device address is C010 E4.

claw      E0

!--- Common Link Access to Workstation (CLAW) uses E0 and E1.

offload   E3

!--- Offload E2 and E3.

csna C010 E4

!--- CSNA E4, on subchannel 7E4.

cmpc      E5

!--- Cisco Multipath Channel (CMPC) uses two subchannels E5 and E6.

Cisco Systems Network Architecture

The CIP CSNA requires a minimum of one subchannel address. This is an example configuration:

interface Channel 0/0

csna 0100 E4 or csna C010 E4

!--- E4 corresponds to the host XCA subchannel address 7E4 for TN3270.

csna 0100 E9 or csna C010 E9

!--- E9 corresponds to the host XCA subchannel 7E9 for CSNA.

interface Channel0/2

ip address 20.1.1.54 255.255.255.0

max-llc2-sessions 4000

!--- Maximum LLC2 connections.

lan TokenRing 0

adapter 0 4000.4040.0000

!--- CIP assumes the XCA SAP 04.

adapter 1 4000.aaaa.aaaa

!--- XCA SAP 12. Adapters must have different SAPs.

lan TokenRing 1

adapter 2 4000.bbbb.bbbb

!--- XCA SAP 04.

tn3270-server

maximum-lus 8000

!--- Each of the next three lines normally appear on one line.

pu JEPU -- 01754321 20.1.1.55 token-adapter 0 44
         rmac 4000.4040.0000 rsap 04 lu-seed JELU##

pu JEPUA 05D2aaaaa 20.1.1.56 token-adapter 1 08
         rmac 4000.aaaa.aaaa -- rsap 12 lu-seed JELUA###

pu JEPUB 05D2bbbbb 20.1.1.57 token-adapter 2 12
         rmac 4000.bbbb.bbbb rsap 04 lu-seed JELUB###

CSNA Command Field

This is the CSNA command field:

path: C010 E4

The path argument has a 4-digit hexadecimal value in the range from 0x0000 through 0xFFFF (two digits for the physical connection, one digit for logical partition number, and one digit for the Control Unit Address). For Parallel Channel Adapter (PCA), Bus and Tag, configure the value 0x0100.

• C0—The Enterprise Systems Connections (ESCON) Director port number to which the physical channel is connected. In the example, the host physical port CHPID=2C is connected to ESCON port C0.

  Configure 01 for all direct connections (no ESCON Director).

• 1—The HOST logical partition number with which CIP communicates is configured as the RESOURCE PART parameter in the IOCP or as the PARTITION NUMBER in the HCD Partition and Channel Path Summary Report.

• 0—The Control Unit Address is configured as the CUADD parameter in the IOCP or HCD Device Detail Report.

• E4—The Device Address (also called a Unit Address) is found in the HCD Device Detail Report as a configuration parameter called UNITADDR, which corresponds to the Device Number 07E4. It can also be calculated from the IOCP configuration parameters with the CSNA Device Address formula in the next section.

Device Address Formulas

This is the basic CSNA device formula:

CSNA Device Address = ( XCA CUADDR [the first subchannel address from IODEVICE ADDRESS range] – IODEVICE ADDRESS ) + UNITADD

The following applies to the previous example:

• The CUADD is 7E4 in the XCA major node.

• The first subchannel address from IODEVICE macro is (7E0,16): 16 addresses that each start with 7E0.

• The UNITADD starts with E0.

Therefore, in the example, CSNA Device Address = ( 7E4 – 7E0 ) + E0 = E4.

You can use the CSNA formula for all other CIP features, such as CMPC, CLAW, and Offload.

For CMPC, replace the XCA CUADDR in the formula with the Transport Resource List Entry (TRLE) subchannel address. For Offload, replace the XCA CUADDR in the formula with the Offload subchannel address configured in the host TCPIP PROFILE.

Therefore, to summarize:

CSNA Device Address = ( CUADDR – IODEVICE ADDRESS ) + UNITADD

CMPC Device Address = ( TRLE – IODEVICE ADDRESS ) + UNITADD

Offload Device Address = ( TCPIP PROFILE Subchannel Address – IODEVICE ADDRESS ) + UNITADD

Keywords

These keywords can adjust the CIP interface transmission characteristics:

csna path device [maxpiu value] [time-delay value] [length-delay value]

Changes to the delay values take effect immediately. Any change to the maximum packet size takes effect after the channel is re-initialized.

A length-delay value of 0 sends the packet as soon as possible. When frames blocked for transmission on the channel accumulate to a total blocked length greater than the length-delay, the block is transmitted on the channel regardless of the time-delay. A length-delay value of 0 indicates that all frames are blocked before transmission on the channel for only the time specified by the time-delay.

When you shut down a channel interface, all subchannels (path and devices) configured on the channel and all LLC2 sessions established over the subchannels are terminated. You should take care not to shut down a channel interface while LLC2 sessions are active over the channel. Terminating LLC2 sessions may require SNA nodes in the network to time-out before they can establish another session.

interface Channel0/2

ip address 20.1.1.54 255.255.255.0

max-llc2-sessions 4000

lan TokenRing 0

adapter 0 4000.4040.0000 -- (XCA SAP 04)

adapter 1 4000.aaaa.aaaa (XCA SAP 12)

!--- XCA major nodes configured on the same CSNA subchannel
!--- must have different SAPs.

max-llc-sessions number

If you set the max-llc-sessions to a value smaller than that to which it is currently set, active sessions will not disconnect; however, no new LLC2 sessions are allowed until the number of active sessions drops below the new max-llc-sessions value.

CIP Internal LAN Configuration for CSNA and CMPC

The CSNA and CMPC features require at least one internal LAN (usually a token ring) to be configured on the CIP virtual interface slot/2. The lan command creates an internal LAN with a unique internal LAN ID on a specific CIP card. The lan command allows for subcommands that enable local SRB or transparent bridging and that define internal adapters. This is syntax for the lan command:

lan type lan-id

When you issue the lan command, the configuration is put into a subinternal LAN configuration mode in which you can specify internal adapters, source bridge, and transparent bridge statements for the internal LAN. Only one source bridge configuration statement may be entered per internal LAN. The rules for the bridge statements are the same as when they are entered as subinterface commands.

source-bridge source-ring bridge-number target-ring

The adapter command is a subinternal LAN command. It is used to configure the RAN and MAC address for LLC2 connections.

adapter adapno mac-address

The llc2 command is configured beneath the adapter command to specify the LLC2 parameters.

llc2 N1 xxxx

Other tuning options are available with the llc2 command; refer to LLC2 and SDLC Commands.

Procedures to Troubleshoot CSNA

The procedures in this section show a concise way to troubleshoot a CSNA connectivity problem. Use the example configurations, diagrams, and notes to help understand the output from the commands that you are asked to issue.

Note: All CSNA-related traffic flows on the CIP virtual interface 2. There is no traffic that flows over port 0 or port 1 on the CIP for CSNA. This is different from the CPA, where all CSNA traffic flows over physical interface 0.

Troubleshoot the Router

Follow the steps in these subsections to verify whether your CSNA connectivity problem is host-related or router-related.

Verify the Operational Status of the CSNA Adapter

First, determine whether you have a problem with the connectivity to the host or a problem with CSNA on the router itself. Issue the show extended channel slot/port csna oper command to display the CSNA channel device state. (Refer to Understanding CSNA States for details.) Verify that the status of the CSNA device is setupComplet.

router1# show extended channel 4/0 csna oper

Path Dv       Status        SlowDown  maxpiu  time-delay  length-delay
CSNA 0100 00  setupComplet  off       20470   10          20470
CSNA 0100 00  setupComplet  off       20470   10          20470

Monitor the CSNA Adapter Statistics

Issue the show extended channel slot/port csna stats command to get statistics for the CSNA channel device. Check that the send and receive counters are incrementing to verify that the CSNA device is passing traffic over the channel to the host XCA major node.

router1# show extended channel 4/0 csna stat

CSNA 0100 00
  Blocks Transmitted           =    257543  Received =    257548
  Bytes Transmitted            =  17210604  Received =  34216084
  Slow downs Sent              =         0  Received =         0
  Txd by maxpiu       : Blocks =         0  Bytes    =         0
  Txd by time-delay   : Blocks =    132672  Bytes    =  15898904       
  Txd by length-delay : Blocks =         0  Bytes    =         0

Verify the SAP Connectivity

Finally, issue the show extended channel slot/port connection-map llc2 command to identify the number of SAPs and connections opened on the CIP. Verify that the correct SAP, as defined on the XCA major node, has been opened on the CIP internal token-ring LAN adapter (for example, LAN Adapter 0). Use the next example output and diagram to see the relationship between the SAP number on the router and the XCA major node.

router1# show extended channel 4/2 connection-map llc2

LAN Token 0 Adapter 0 4000.7507.0000
 Local SAP=04 LLC2 Connections=5 CSNA Port=0 Path=0100 Device=00

LAN Token 0 Adapter 1 4000.7507.ffff
 Local SAP=04 LLC2 Connections=1 CSNA Port=0 Path=0100 Device=01

LAN Token 0 Adapter 0 4000.7507.0001
 Local SAP=04 LLC2 Connections=1 CSNA Port=0 Path=0100 Device=00

!--- Verify that the SAP number that you have configured on the
!--- XCA major node matches the SAP number configured in the
!--- ADAPTNO statement in the CIP router definition
!--- (#4 in the next diagram).

Total: SAPs opened = 5   Connections active = 9

router1#

This sample CIP configuration shows the virtual interface, the CIP VLAN, the source bridge, and the internal adapter number that matches the ADAPTNO on the XCA Major Node:

interface Channel4/2
 lan TokenRing 0
  source-bridge 88 1 100
  adapter 1 4000.7507.ffff

Note: CIP assumes that the LSAP is 04 from the XCA major node (see the next configuration from the XCA major node).

VBUILD TYPE=XCA
*
APPNPRT PORT ADAPTNO=1,

!--- This matches the internal adapter number of the previous
!--- example CIP configuration output.

        CUADDR=401,        DEFAULT TABLE ENTRY
        MEDIUM=RING        MODE TABLE FOR MODEL 3
        SAPADDR=4,         3270 DISPLAY TERMINAL

!--- This is the SAP number to which the XCA major node listens.
!--- If this value does not match with your end stations, then
!--- the XCA major node does not respond to their XIDs.

        TIMER=10
*
APPNGRP GROUP DIAL=YES, CU ADDRESS PORT A01
        ANSWER=ON,         DEFAULT TABLE ENTRY
        DYNPU=YES,         MODE TABLE FOR MODEL 4
        AUTOGEN=(16,L,P),  INITIAL ACTIVE

!--- This automatically generates sixteen logical lines
!--- that start with the letter L and generates physical
!--- units that start with the letter P.

        CALL=INOUT         3270 DISPLAY TERMINAL

If the CSNA channel device (subchannel) is setupComplet and the correct SAP (SAP 04) is open on the correct CIP internal MAC adapter, connectivity to the host should be established. However, if the CSNA channel device (subchannel) does not have status setupComplet, see Troubleshoot the Host to verify the host to router connectivity.

If the problem persists, continue to troubleshoot: verify that the CSNA internal adapter has been acknowledged by the Route Switch Processor (RSP) card and that traffic is flowing through it. You can either turn on a debug to watch the traffic flow, display the status of the CSNA adapter, or monitor the statistics on traffic flow.

Debug the Source-Bridge Traffic

Issue the debug source bridge command to view the source-routed Logical Link Control (LLC) traffic passed into the CSNA internal adapter. The next diagram shows how a sample router configuration—which shows the ring numbers and the CIP internal adapter MAC address—relates to sample output from the debug source bridge command.

Note: The ring numbers in the debug source bridge output appear in decimal, but they appear in hexadecimal in the Routing Information Field (RIF). Use the RIF to work out the path to the remote device. Match the ring numbers and the MAC address in the CIP configuration to the debug output, to verify that packets are being sent across the adapter.

Verify the LAN Status of the CSNA Adapter

Turn on debug channel vlan. This debug displays the last column in the next command output. Issue the show extended channel port/slot lan command to display the CIP internal MAC adapters. Verify that you see the status ACK (Acknowledged), which indicates that the CSNA internal MAC adapter’s CIP microcode has been acknowledged by Cisco IOS Software CIP driver code.

router1# show extended channel 4/2 lan

lan TokenRing 0
  source-bridge 88 1 100
  Adapno  MAC Address     Name  Vcnum
    0     4000.7507.0000  544   0041  ACK ... ... ... ... ... INV
    1     4000.7507.ffff  545   0041  ACK ... ... ... ... ... INV
    2     4000.7507.0001  546   0041  ACK ... ... ... ... ... INV
    3     4000.7507.00ff  547   0041  ACK ... ... ... ... ... INV
    4     4000.7506.0000  548   0041  ACK ... ... ... ... ... INV

Note: If the CIP internal MAC adapters have not been acknowledged by the CIP—that is, you see anything other than ACK status, such as CRE (Create) or PND (Pending)—then the CIP microcode has not acknowledged the CIP adapter configuration command from the Route Processor. In this case, the Route Processor card does not forward explorers to the CIP.

Also, if the CSNA internal MAC adapter CIP microcode has not been acknowledged by Cisco IOS Software—that is, instead of ACK status, you see either CRE or PND status in the output—then the RSP will not forward traffic to the CSNA internal MAC adapter.

In this situation, issue a shut and then issue a no shut on the physical interface 0 of the CIP card. This re-initializes the connection between the CIP microcode and the Cisco IOS Software CIP driver code.

Caution: This command disrupts the CIP card. It will reset all existing TCP and LLC2 sessions that are currently active through the CIP card.

After the shut and no shut, if the CSNA adapter is still not in ACK status, you must reload the CIP card’s microcode. Enter global configuration mode and issue the microcode reload command.

Caution: This command disrupts all of the interface processor cards. It will reset all existing TCP and LLC2 sessions that are currently active through the CIP card. Also, in a 7500 CIP router, all interface processor cards are quiesced during the microcode reload.

Monitor the Test Poll Counters

If the CSNA internal MAC adapter has been acknowledged by Cisco IOS Software and traffic is being received on the router, issue the show extended channel slot/port llc stat zzzz.zzzz.zzzz command, where zzzz.zzzz.zzzz is the CSNA adapter internal MAC address. This displays the traffic counters and verifies whether the CSNA MAC adapter is receiving and responding to TEST polls.

router1# show extended channel 4/2 llc stat 4000.7507.0000

LAN Token 0 Adapter 1 4000.7507.0000
  PDUsIn      =   286379  PDUsOut     =   285123
  OctetsIn    = 18943996  OctetsOut   = 18920536
  TESTCmdsIn  =     1025  TESTRspsOut =       36
  LocalBusies =        0  UnknownSAPs =       16

Monitor the XID Exchange Counters

If you see the TESTCmdsIn and TESTRspsOut counters increment, the internal MAC adapter is receiving and sending TEST frames. Issue the show extended channel slot/port llc stat zzzz.zzzz.zzzz yyy command, where zzzz.zzzz.zzzz is the CIP internal MAC address and yyy is the SAP number. If you monitor the XIDCmdsIn, XIDCmdsOut, XIDRspsIn, and XIDRspsOut counters, you can verify whether the SAP is receiving and responding to XIDs.

If the SAP is not responding, one of these error conditions might apply:

• The SMN might not be active.

• The IDBLK or IDNUM might not be valid.

• The PU might already be in use by a different end-station.

Use this example output to help understand the traffic counters:

router1# show extended channel 4/2 llc2 stats 4000.7507.0000 04

LAN Token 0 Adapter 0 4000.1010.2020
  Local SPA=04
    TESTRspsIn     =  0   TESTCmdsOut    =  0
    XIDCmdsIn      =  14  XIDCmdsOut     = 16
    XIDRspsIn      =  4   XIDRspsOut     =  0
    UIFramesIn     =  0   UIFramesOut    =  0
    UIOctetsIn     =  0   UIOctetsOut    =  0
    ConnectOk      =  2   ConnectFail    =  0
    DiscNorm       =  0   DiscByTmr      =  0
    DiscByFRMRSent =  0   DiscByFRMRRcvd =  0
    DMsInABM       =  0   SABMEsInABM    =  0

See the Verify the Switched Major Node section.

Troubleshoot the Host

Follow the steps below to troubleshoot your CSNA connectivity problem on the host.

Verify the Status of the XCA Major Node

Issue the DISPLAY command shown in the next diagram to verify that the XCA major node is active. Use the notes for the next diagram to help you troubleshoot.

This sample CIP configuration shows the virtual interface, the CIP VLAN, the source bridge, and the internal adapter number that matches the ADAPTNO on the XCA Major Node:

interface Channel4/2
 lan TokenRing 0
  source-bridge 88 1 100
  adapter 1 4000.7507.ffff

Note: CIP assumes that the LSAP is 04 from the XCA major node (see the next configuration from the XCA major node).

VBUILD TYPE=XCA
*
APPNPRT PORT ADAPTNO=1,

!--- This matches the internal adapter number of the previous
!--- sample CIP configuration output.

        CUADDR=401,        DEFAULT TABLE ENTRY
        MEDIUM=RING        MODE TABLE FOR MODEL 3
        SAPADDR=4,         3270 DISPLAY TERMINAL

!--- This is the SAP number to which the XCA major node listens.
!--- If this value does not match with your end stations, then
!--- the XCA major node does not respond to their XIDs.

        TIMER=10
*
APPNGRP GROUP DIAL=YES, CU ADDRESS PORT A01
        ANSWER=ON,         DEFAULT TABLE ENTRY
        DYNPU=YES,         MODE TABLE FOR MODEL 4
        AUTOGEN=(16,L,P),  INITIAL ACTIVE

!--- This automatically generates sixteen logical lines
!--- that start with the letter L and generates physical
!--- units that start with the letter P.

        CALL=INOUT         3270 DISPLAY TERMINAL

Verify the Subchannel Address

To determine if the devices are online, issue the D U,,,xxx,2 command from the system console, where the subchannel address xxx refers to the CUNUMBER in the IOCP generation or the CUADDR (Control Unit Address) in the XCA major node. The output looks something like this:

To vary the devices online, issue the V xxx-yyy,ONLINE command from the system console, where xxx refers to the starting subchannel address and yyy refers to the ending subchannel address. Be sure to wait for the output of this command, to ensure that it completed successfully. To vary the devices offline, issue the V xxx-yyy,OFFLINE command.

Verify the Host Physical Channel

To determine if the host physical channels (paths) are online for the device, issue the D M=DEV(xxx-xxx) command from the system console, where xxx refers to the device number that you want to check. The output looks something like this:

To vary the path to the device online, issue the V PATH(xxx-yyy,zz),ONLINE command from the system console, where xxx refers to the starting physical channel address, yyy refers to the ending physical channel address, and zz refers to the path that you wish to vary online. Be sure to wait for the output of this command, to ensure that it completed successfully. To vary the path to the device offline, issue the V PATH(xxx-yyy,zz),OFFLINE command.

Verify the Channel Path Identifier

To determine if the CHPID is online for the device, issue the D M=CHP(xx) command from the system console, where xx refers to the CHPID number that you wish to check. The output looks something like this:

To vary the CHPID online, issue the CF CHP(xx),ONLINE command from the system console, where xx refers to the CHPID that you wish to vary online. Be sure to wait for the output of this command, to ensure that it completed successfully. To vary the CHPID offline, issue the CF CHP(xx),OFFLINE command.

Verify the Switched Major Node

Issue the DISPLAY command shown in the next example output to verify that the SMN is active.

NCCF         TME 10 NetView      CNM01 OPER6 03/31/00 13:59:43
C CNM01  DISPLAY NET,ID=DKTN3270,SCOPE=ALL

!--- NetView takes the DIS DKATN3270 shorthand and converts it
!--- into the full DISPLAY NET,ID=DKTN3270,SCOPE=ALL command.

  CNM01  IST0971 DISPLAY ACCEPTED
' CNM01
IST0751  NAME = DKTN3270 , TYPE = SW SNA MAJ NODE
IST4861  STATUS =  ACTIV , DESIRED STATE = ACTIV
IST16561 VTAMTOPO = REPORT , NODE REPORTED = YES
IST0841  NETWORK RESOURCES:
IST0891  DK3270DY TYPE=PU_T2.1        , ACTIV

!--- Verify that the PU is in ACTIV status.
!--- If the PU is in INACT or INOP status then ask the System Programmer or
!--- Network Operator to activate it.
!--- If the PU is in CONNECT status then you might have a definition error;
!--- ask the System Programmer to verify the SMN definition.
!--- If the PU is in ACTIVE status and you still can not establish a session,
!--- verify that another end station is not using this PU.

IST0891  DKDYLU0A TYPE = LOGICAL UNIT , ACTIV---X-
IST0891  DKDYLU1B TYPE = LOGICAL UNIT , ACT/S---X-
IST0891  DKDYLU1A TYPE = LOGICAL UNIT , ACTIV---X-
IST0891  DKDYLU19 TYPE = LOGICAL UNIT , ACT/S---X-
IST0891  DKDYLU18 TYPE = LOGICAL UNIT , ACT/S---X-
IST0891  DKDYLU17 TYPE = LOGICAL UNIT , ACT/S---X-
IST0891  DKDYLU16 TYPE = LOGICAL UNIT , ACT/S---X-
IST0891  DKDYLU15 TYPE = LOGICAL UNIT , ACT/S---X-
IST0891  DKDYLU09 TYPE = LOGICAL UNIT , ACTIV---X-
IST0891  DKDYLU08 TYPE = LOGICAL UNIT , ACTIV---X-
IST0891  DKDYLU07 TYPE = LOGICAL UNIT , ACTIV---X-
IST0891  DKDYLU06 TYPE = LOGICAL UNIT , ACTIV---X-
IST0891  DKDYLU05 TYPE = LOGICAL UNIT , ACTIV---X-
IST0891  DKDYLU04 TYPE = LOGICAL UNIT , ACTIV---X-
IST0891  DKDYLU03 TYPE = LOGICAL UNIT , ACTIV---X-
IST0891  DKDYLU02 TYPE = LOGICAL UNIT , ACTIV---X-
IST0891  DKDYLU01 TYPE = LOGICAL UNIT , ACTIV---X-
IST0891  DK3270ST TYPE = PU_T2        , CONCT
IST0891  DKSTLU01 TYPE = LOGICAL UNIT , CONCT
IST0891  DKSTLU02 TYPE = LOGICAL UNIT , CONCT
IST0891  DKSTLU03 TYPE = LOGICAL UNIT , CONCT
IST0891  DKSTLU04 TYPE = LOGICAL UNIT , CONCT
IST0891  DKSTLU05 TYPE = LOGICAL UNIT , CONCT
IST0891  DKSTLU06 TYPE = LOGICAL UNIT , CONCT
IST0891  DKSTLU07 TYPE = LOGICAL UNIT , CONCT
IST0891  DKSTLU08 TYPE = LOGICAL UNIT , CONCT
IST0891  DKSTLU09 TYPE = LOGICAL UNIT , CONCT
IST0891  DKDLUR32 TYPE = PU_T2.1      , ACTIV--L--
IST0891  DKDLDYPU TYPE = PU_T2.1      , ACTIV
IST0891  DKDLSTPU TYPE = PU_T2.1      , ACTIV
IST0891  DKDLST01 TYPE = LOGICAL UNIT , ACTIV
IST0891  DKDLST02 TYPE = LOGICAL UNIT , ACTIV
??? ***


VBUILD TYPE = SWNET
*
* TN3270 DYNAMIC LU BUILD
*
DK3270DY PU ADDR=01,
            IDBLK=05D,
            IDNUM=03270,

!--- Verify that the end station is using the correct IDBLK and IDNUM.

            PUTYPE=2,
            LUGROUP=BXLLUGRP,LUSEED=DKDYLU##
*           LUGROUP=BXLLUGRP,LUSEED=DKDYLU##
*
*
* TN3270 CP DEF FOR DLUR EN ON CIP
*
DKDLUR32 PU ADDR = 01,
            CPNAME=DK3270CP,

!--- Verify that the end station is using the correct CPNAME.

            ISTATUS=ACTIVE,
            PUTYPE=2,
            CPCP=YES,
            NETID=NETA

Common CSNA Problems

This section explains some of the most common CSNA problems and provides recommended solutions for each one. Check to see if your problem falls into one of these categories, and then follow the recommended solution for it.

1. End station gets no response to test poll.

2. End station gets no response to NULL/IEEE XID.

3. End station gets no response to XID0 or XID3.

4. VTAM to PU4 or VTAM to VTAM through CSNA fails to connect.

5. CSNA sessions drop when things get busy.

6. The end station nth user can not get the CSNA connection.

7. End user indicates invalid frame received from VTAM and tears down the session.

8. Everything is fine through XID exchange, including PU and LU activation, but the user never sees the VTAM splash screen.

9. Connection problem in duplicate MAC address environment.

10. SDLLC connection that uses RSRB or DLSw+ is not coming up when switched to CSNA from FEP 3745.

11. 7000-CIP, FEP 3745, and SAA Gateway are all connected to the same token ring. No connection between SAA Gateway to VTAM when switched to CSNA from FEP 3745.

12. Unable to bring up APPC Networking Services for Windows (NS/WIN) and the IBM PC/3270 for Windows (PC/3270) at the same time in a LAN environment. When both start at the same time, whichever program starts first works fine, but the other program hangs.

End station gets no response to test poll.

CSNA will not respond to TEST unless an SAP is open. The SAP is open when the XCA major node is activated.

1. Issue the V NET,ACT,ID=node-name command to ensure that the XCA major node is active.

2. Ensure that the RAN opened in the XCA major node corresponds to the correct adapter number or MAC address on the CSNA internal adapter for the connection.

3. If the SAPADDR in the XCA major node is not 4, and the downstream devices (Synchronous Data Link Control [SDLC]-to-LLC2 conversion [SDLLC], Qualified Logical Link Control [QLLC]) default to 4, then a failure symptom shows up as no response to the (NULL) XID, but a response is received to the TEST.

End station gets no response to NULL/IEEE XID.

1. Ensure that the SAP activated in the XCA major node matches the destination SAP for the connection.

2. Ensure that the end station users have not exceeded the allowed number of active connections (specified by the AUTOGEN parameter in the XCA major node) for this XCA definition. When you have exceeded the allowed number of active connections, VTAM ignores the NULL XID.

End station gets no response to XID0 or XID3.

1. Check the SMN definition for an IDNUM, IDBLK, or CPNAME mismatch. In such a case, VTAM might display an error message, if you have not opted to filter out this message.

2. The IDNUM, IDBLK, or CPNAME might already be in use by another end station. Issue the DISPLAY command D NET,ID=node-name to check the status of the PU in VTAM. The PU should be in connectable (CONCT) state.

VTAM to PU4 or VTAM to VTAM through CSNA fails to connect.

In each of these cases, VTAM sends a spanning explorer (single route broadcast). You must have source-bridge spanning configured on the intervening token-ring or FDDI interfaces.

CSNA sessions drop when things get busy.

Currently, CSNA defaults to a 7-frame LLC send window. The 3745 and 3172 routers default to much lower values. If CSNA is sending a lot of outbound data and exceeds the allowed send window size, the receiver might send an FRMR and tear down the session.

Configure llc2 local-window 1 under the CIP Internal Adapter to fix this problem.

The end station nth user can not get the CSNA connection.

The nth user may have exceeded the maximum LLC connection limit. The max-llc2-sessions per CIP defaults to 256. The current code of CSNA does not send an ALERT; the only way to tell that this problem is occurring is to issue a show extended channel slot/port max-llc2-sessions command. The count for number exceeded should be 0.

End user indicates invalid frame received from VTAM and tears down the session.

Check for possible mismatch for the MAXDATA value at the end station. The debug channel events sna command provides this error indication:

Connection failed/FRMR rxd - I-field too long

Everything is fine through XID exchange, including PU and LU activation, but the user never sees the VTAM splash screen.

From a CSNA perspective, everything after the UA is LLC connection data passed to VTAM. However, it is important to know that the USSMSG10 message is potentially the first large I-frame.

Connection problem in duplicate MAC address environment.

1. Check the RIF to ensure that you are dealing with the expected CSNA connection, especially in duplicate MAC address situations.

2. Issue the show extended channel slot/2 connection-map llc command to see the current number of active connections per SAP.

SDLLC connection that uses RSRB or DLSw+ is not coming up when switched to CSNA from FEP 3745.

Check for a possible error in the MAC address in the tr partner statement in the SDLLC router definition. This MAC address should point to the CIP internal token ring and not to the FEP token ring.

7000-CIP, FEP 3745, and SAA Gateway are all connected to the same token ring. No connection between SAA Gateway to VTAM when switched to CSNA from FEP 3745.

1. With a Sniffer, check to determine whether the Systems Application Architecture (SAA) Gateway is sending an explorer frame with a broadcast bit turned off.

2. The SAA Gateway needs to run Route.nlm (a program module) for SRB; and, in this case, Route.nlm is not loaded into the SAA Gateway. The network works when the SAA Gateway is directly connected to the FEP 3745, which did not require a RIF. However, when the SAA Gateway is switched to CSNA, even though the 7000-CIP is physically directly connected, the SAA Gateway is logically one hop away from the 7000-CIP. Due to the CSNA internal ring, CSNA must have the RIF in this case.

3. You can use the DSPU to force the router to generate a route explorer, when devices such as the SAA Gateway do not participate in SRB in particular cases.

Unable to bring up APPC Networking Services for Windows (NS/WIN) and the IBM PC/3270 for Windows (PC/3270) at the same time in a LAN environment. When both start at the same time, whichever program starts first works fine, but the other program hangs.

The problem is that two different SNA communications subsystems are started at the same time: one providing SNA service for the LU 2 (PC/3270) and one providing services for the LU 6.2 (NS/WIN). By default, both want to use the same SAP, X'04', when they communicate through the same CIP internal adapter. When the first subsystem communicates to the adapter, it informs the adapter that it will use SAP X'04'. When the second subsystem attempts to inform the adapter that it also wants to use SAP X'04', the adapter prevents this, because the adapter would not be able to distinguish between the incoming data from these two subsystems.

The solution is to use SAP X'04' for one subsystem and change the other subsystem’s SAP to X'08' or to the next highest unused multiple of 4.

MSG802-6-BADNS_WARN Messages and How to Tune the LLC2 Window

The MSG802-6-BADNS_WARN message, included in CIP microcode 22-17 and later, indicates possible tuning problems with the LLC2 window sizes. The intent of CIP 22-17 is to make the CIP behave like the IBM 3172 and the IBM 3745 routers. The LLC2 specifications state that if one remote station sends more I-frames than the receiving station can acknowledge at one time, the LLC session is torn down with an FRMR. This action impacts all users of that LLC session. However, for the IBM 3172 and the IBM 3745, rather than tear down the LLC session with a FRMR, a reject (REJ) is sent that instructs the sending station to start to send frames again, starting with the I-frame noted in the REJ. The LLC session is maintained. When the CIP receives a MSG802-6-BADNS_WARN message that indicates that a remote station has sent the CIP adapter more I-frames than it can acknowledge at one time, the CIP sends a REJ instead of tearing down the LLC session with a FRMR.

The next configuration and show commands indicate the number of LLC2 sessions open on a particular adapter, along with the current operational parameters. The configurations demonstrate how to detect the remote MAC address that is exceeding the LLC2 window size and is causing the BADNS message. They also demonstrate how to tune the LLC2 window size to prevent this behavior.

This CIP router configuration shows one adapter:

interface Channel4/2
 max-llc2-sessions 30
 lan TokenRing 0
  source-bridge 50 1 101
  adapter 0 4000.7507.0000
   name cip7t0a0
   llc2 t1-time 3000

This output shows that there are five LLC2 sessions open:

HOST-C# show extended channel 4/2 connection-map llc

LAN Token 0 Adapter 0 4000.7507.0000
Local SAP=04 LLC2 Connections=5 CSNA Port=0 Path=C060 
Device=A0

This output shows the current LLC operational parameters:

HOST-C# show extended channel 4/2 llc admin

Lan Token 0 adapter 0 4000.7507.0000
t1-time   =  3000   tpf-time  = 1000   trej-time = 3200 tbusy-tim = 9600
idle-time = 60000   local-win =    7   recv-wind =    7 N2        =    8
N1        =  4105   ack-delay =  100   ack-max   =    3 Nw        =    0

Notice that the receive window parameter is set to 7, which means that this adapter receives seven frames before it must send an acknowledgment for some or all of the I-frames. If the remote station sends eight or more consecutive I-frames, the previous configuration indicates that the CIP adapter has detected a BADNS (incorrect number sent count).

You can determine the MAC address of the remote station that sent the excess I-frames, if you issue this command before the BADNS message has been posted in the router log for thirty minutes:

HOST-C# if-con 4 c

Entering CONSOLE for CIP2 4
Type "^C^C^C" or "if-quit" to end this session

CIP-Slot4# llc badns

pcep=0132 rmac=0006.7c99.c687 lmac=C000.7507.0000  rsap=EC lsap=04 this=810F8618
rif=08B0.0501.0651.08B0.0000.0000.0000.0000.0000 ack-len=0000

CIP-Slot4# if-quit

Disconnecting from slot 4 CONSOLE after 00:00:14

HOST-C#>

Note:  lmac=C000.7507.0000 is the CIP adapter 0. The high-order bit indicates that a RIF is present.

You can see that MAC address 0006.7c99.c687 with SAP EC caused the BADNS message.

This output shows the details of the LLC connection between the CIP and the address that caused the BADNS message:

HOST-C# show extended channel 4/2 llc stat 4000.7507.0000 * 0006.7c99.c687

LAN Token 0 Adapter 0 4000.7507.0000
  Local SAP=04 Remote MAC=0006.7c99.c687 Remote SAP=04
    LocalBusies    =          0  RemoteBusies   =         0
    IFramesIn      =         58  IFramesOut     =       290
    IOctetsIn      =      11989  IOctetsOut     =     27647
    SFramesIn      =        556  SFramesOut     =       444
    REJsIn         =          0  REJsOut        =         1
    RetransmitsOut =          0  WwCountChanges =         0

There are two methods to correct this problem:

1. Increase the CIP adapter receive window size.

2. Decrease the offending station’s send window size.

Method 2 is recommended. If you change the CIP adapter receive window size (method 1), the larger window would be in place for all LLC connections to the adapter and would affect all stations using this adapter. If only one remote station is causing the problem, change that remote station.

To change the CIP adapter receive window size:

1. Issue these commands, in order:

   HOST-C# config t
   
   Enter configuration commands, one per line. End with CNTL/Z.
   
   HOST-C(config)# interface channel 4/2
   
   HOST-C(config-if)# lan tokenring 0
   
   HOST-C(cfg-lan-Token 0)# adapter 0
   
   HOST-C(cfg-adap-Token 0-0)# llc recv-window 11
   
   HOST-C(cfg-adap-Token 0-0)# end>
   

2. Issue the write memory command to save the configuration.

   HOST-C# write memory
   
   Building configuration...
   [OK]
   
   HOST-C#

3. Check the configuration:

   interface Channel4/2
    max-llc2-sessions 30
     lan TokenRing 0
      source-bridge 50 1 101
      adapter 0 4000.7507.0000
       name cip7t0a0
       llc2 recv-window 11
       llc2 t1-time 3000

4. Check the LLC operational parameters:

   HOST-C# show extended channel 4/2 llc admin 4000.7507.0000
   
   Lan Token 0 adapter 0 4000.7507.0000
   t1-time   =  3000  tpf-time  = 1000  trej-time = 3200  tbusy-tim = 9600
   idle-time = 60000  local-win =    7  recv-wind =   11  N2        =    8
   N1        =  4105  ack-delay =  100  ack-max   =    3  Nw        =    0

Notice that the LLC receive window is now 11 frames. This does not affect sessions that have already started. You must inactivate and reactivate the XCA major node for the new parameter to take effect. Unless you want to affect all LLC sessions on the CIP adapter, change the transmit window on the offending station to a value lower than the CIP adapter’s receive window. For example, if the CIP adapter receive window is 7, set the station’s transmit window to 5.

NetPro Discussion Forums - Featured Conversations

Related Information

• CSNA (Cisco Systems Network Architecture) Product Support Page
• Technology Support
• Product Support
• Technical Support - Cisco Systems