Document ID: 12357
Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
Network Control Program (NCP) SDLC Addressing Considerations
Note on NCP Echo Defeat Support
Considerations Before seconly Option
Considerations After seconly Option
Virtual Telecommunications Access Method (VTAM)/NCP and Router Configuration Considerations
SDLC Role in Router
SDLC Modulo Support
SDLC Interface Maximum Transmission Unit (MTU) Size
VTAM/XCA Limitations
Miscellaneous Settings
XID2 Frame Format
FEP/CIP Scenarios
FEP to FEP - SDLC without Router
FEP to ICA - SDLC without Router
FEP to FEP - TR to SDLC with TR FEP with Highest Subarea Number
FEP to FEP - TR to SDLC with SDLC FEP with Highest Subarea Number
CIP to SDLC FEP - with CIP with Highest Subarea Number
CIP to SDLC FEP - with SDLC FEP with Highest Subarea Number
CIP to SDLC FEP - Using seconly Option
Sample Configurations
DLSw Remote Peer Connection (Two Routers)
DLSw Local-Switching Connection (One Router)
NCP and VTAM Sample Configurations
Verify
Troubleshoot
Troubleshooting Procedure
NetPro Discussion Forums - Featured Conversations
Related Information
Introduction
The Synchronous Data Link Control (SDLC) to Logical Link Control, type 2 (LLC2) conversion for FID4 frames is a data-link switching (DLSw+) feature available in IOS® Software Release11.3T and later releases. This feature allows communication in these scenarios:
-
SDLC-attached front end processor (FEP) to LAN-attached FEP across an IP cloud using DLSw+
-
SDLC-attached FEP to a Channel Interface Processor (CIP) mainframe-attached router across an IP cloud using DLSw+
-
SDLC-attached FEP to LAN-attached FEP: both FEPs are attached to the same router (DLSw+ Local Switching)
-
SDLC-attached FEP to CIP: both the CIP and FEP are attached to the same router (DLSw+ Local Switching)
This feature reduces costs by allowing network consolidation of links carrying FEP traffic. It provides a smooth migration from a FEP to a CIP. It also enables DLSw+ to transport Systems Network Administration (SNA) Network Interconnection (SNI) traffic between FEPs when one of the FEPs is serially attached.
The feature received a major improvement with the introduction of software defect CSCdm00503, which was integrated in IOS Software Releases 11.3(10)T, 12.0(5) and 12.0(5)T. If using the first and second scenarios, only the router next to the SDLC FEP needs to run the level of IOS previously indicated. The third and fourth scenarios require the IOS upgrade.
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:
-
CSCdm00503, which was integrated in IOS Software Releases 11.3(10)T, 12.0(5) and 12.0(5)T
Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Network Control Program (NCP) SDLC Addressing Considerations
The single most important consideration is the method in which NCP determines the polling SDLC address on a physical unit 4 (PU4)-to-PU4 link. NCP determines the poll sdlc address to use (if it is primary) from the location of the line definition within the NCP gen deck relative to the start and other lines defined for PUTYPE=4 (subarea connections). Hence, the first PU4 line in the deck uses SDLC address 0x01, the second line uses 0x02, and so on. IBM recently changed the method how address assignments are issued for Internode Network (INN) links. Now, both INN and switched connections are counted for addresses. This means that Token Ring user adapter control blocks (UACBs) are included.
The enhancements, introduced by CSCdm00503, include a new configuration option called seconly which applies to the sdlc address command. For example:
sdlc address 01 seconly
Note on NCP Echo Defeat Support
The IBM Informational APAR II02209 explains the detection and handling of line errors caused by line facility echo. Echo defeat code has been added to NCP INN link support to recover from echoed SDLC frames. This is performed by using dissimilar addressing between NCPs when they are operating in a non-configurable state, such as a primary/secondary relationship. When in this state, the primary station sends the SDLC addressing character (from 0x01 to 0x7E) with bit 0 = OFF. The secondary station sends the addressing character with bit 0 = ON. If the primary receives a frame with bit 0 = OFF, it assumes the frame is an echo and retransmits the frame. If the secondary receives a frame with address character (bit 0 = ON), the same assumption is made and the frame is retransmitted by the secondary. For example, if primary uses address 0x04, the secondary responds using 0x84.
Echo defeat support is agreed by both sides during the exchange identification (XID) negotiation. For that purpose, exchange identification format 2 (XID2) includes the echo supported bit, byte 0x24 bit 4.
Considerations Before seconly Option
Before CSCdm00503 and the seconly option, it was recommended configuring the SDLC links to IBM routers as near to the top of the configuration deck as possible. This ensured that subsequent configurations did not change the relative position of those lines in the generation (gen) deck.
It was also recommended that links be in a group of their own at the top of the deck, and that any additional related links are configured in order of receipt at the end of the group. Then, all remaining non-Cisco lines configured after this group.
After this, if the SDLC-attached FEP had the highest subarea number, you needed to count the number of lines in the gen deck. Then, you configured the appropriate sdlc address in the router.
Another issue that needed to be considered before CSCdm00503, was that the SDLC-attached FEP must be the SDLC primary device. Generally, the FEP with the highest subarea number becomes the primary device. Under such conditions, customers needed to ensure that this was the case on their setup.
The changes introduced by CSCdm00503 greatly improved the previous issue.
Considerations After seconly Option
With the introduction of the seconly option, there is no need to count the number of lines in the NCP deck. This simplifies the configuration process.
This new parameter forces the SDLC-attached FEP to always become the primary device, regardless of the subarea number. Also, the seconly option turns the echo supported bit OFF. The Token Ring-attached FEP or CIP side is forced to be secondary. The implication of this change is that it allows the SDLC router to use any SDLC address. There is no longer the need to count the number of lines present in the NCP deck. You can configure any SDLC address value in the router.
With seconly configured, this is the expected flow of SDLC frames:
-
XID negotiation takes place between both FEPs. On the SDLC side, all XIDs flow addressed to the broadcast SDLC address (0xFF).
-
When XID exchange finishes, the SDLC FEP sends an FF93. For example, all stations Set Normal Response Mode (SNRM) command.
-
The SDLC-attached router responds with an Unnumbered Acknowledgment (UA) with the form xx73, where xx is the configured SDLC address in the router.
-
Communication continues using SDLC address xx. Note that the value xx was randomly chosen by the Network Administrator and that it does not match any other parameter in NCP or the router configuration.
Note: It is recommended to always use the seconly option.
Virtual Telecommunications Access Method (VTAM)/NCP and Router Configuration Considerations
SDLC Role in Router
Before CScdm00503, the SDLC-attached FEP had to be the SDLC primary device. There are two methods to achieve this:
-
Assign a higher subarea number to the SDLC-attached FEP.
-
Do not configure a secondary SDLCST entry on the GROUP statement for the SDLC line. For example:
SDLCPRIM SDLCST GROUP=xxxx SDLCSEC SDLCST GROUP=yyyy GROUP SDLCST=(SDLCPRIM,) NAME1 LINE ADDR=nnn NAME2 PU PUTYPE=4
With the seconly enhancement, the SDLC-attached FEP is always primary and there is no need to make any changes to the NCP configuration.
SDLC Modulo Support
This feature only supports MODULO 8 for the SDLC connection. Always ensure that the SDLC group/line and SDLCST groups have MODULO = 8 and MAXOUT = 7 configured.
SDLC Interface Maximum Transmission Unit (MTU) Size
When determining SDLC interface MTU size, perform these steps:
-
Configure the SDLC interface MTU size of the route to be slightly larger than the value of the maximum packet size that NCP sends down the line. The maximum amount of data a line can send is TRANSFR * BFRS - 18 (BFRS on build statement, TRANSFR is coded on the line, 18 is the NCP buffer header size).
-
Alternatively, check the value of MAXDATA in the channel attach major nodes for the FEP as the FEP cannot send a packet bigger than it can receive from VTAM.
-
Code SDLC N1 equal to (MTU+ 2) * 8. This is the MTU size plus 2 bytes (of SDLC header). N1 is coded in bits (hence * 8). MTU is coded in bytes. For example, common values are:
-
mtu 4096
-
sdlc n1 32784
-
VTAM/XCA Limitations
This diagram is not strictly supported. This is because of a known limitation of VTAM. You cannot own a remote NCP through an external communications adapter (XCA) major node. In this case, the remote NCP must be owned by another VTAM.
Miscellaneous Settings
-
If the router provides clock to the FEP, code the clockrate. For example: clockrate 9600.
-
Configure nrzi-encoding if the FEP SDLC line has NRZI=YES. By default, router uses NRZ encoding.
-
Configure half-duplex if the FEP SDLC line has DUPLEX=HALF. By default, router uses FULL duplex.
XID2 Frame Format
XID commands and responses enable communicating link stations to establish mutually-acceptable link station roles and link characteristics. These commands and responses also convey certain node characteristics and capabilities before they transmit data. There are several XID formats used, depending on the type of end devices. XID format 2 type 4 (XID24) is used for T4/5 to T4/5 subarea node exchanges.
Throughout this document, some of the most relevant bytes in the XID frame are explained. For example: bytes 18, 19, 20, 35 and 38. The bits and bytes, in decimals, of the received or transmitted XID2 are explained in this table:
|
Bytes |
Value |
|---|---|
|
8 |
bit 0 = 1 - Transmission group (TG) active bit 1 = 1 - Multilink TG support |
|
11-12 |
Maximum path information unit (PIU) that this NCP can receive |
|
13 |
TG number |
|
14-17 |
Subarea address of the sender |
|
18 |
This is the error byte. Values for bits 1 - 4:
|
|
19 |
0x00 - Contact has been received by XID sender. 0x07 - XID response sender is already loaded (sent by secondary only). 0x09 - Load required |
|
20-27 |
The initial program load (IPL) name is in extended binary-coded decimal interchange code (EBCDIC). |
|
30 |
01 - SDLC 02 - Channel-to-FEP 03 - Channel-to-channel 04 - Write multipath channel 05 - Read multipath channel |
|
31 |
1 = 1 - Asynchronous Balanced Mode (ABM) combined station 2 = 1 - Secondary network node 3 = 1 - Primary network node |
|
32-33 |
Maximum iframes the sender can receive |
|
35 |
4 = 1 - Echo is supported |
|
38 |
Maxout. If the value is less than 7 = mod8; if it is greater than 7 = mod128 |
FEP/CIP Scenarios
This section displays several network scenarios where NCP SDLC addressing issues can occur. The objective is to inform you about the flow of frames associated with each example. The section starts with a basic FEP-to-FEP SDLC (no router) example and progresses from there, adding routers and CIP cards. The advantages of using the seconly option are evident in this section. Refer to the Sample Configurations section of this document for more information.
Note: Throughout this section, the character (@) is used to represent the hex value of SDLC addresses. Common SDLC control field types, such as SNRM, Set Normal Response Mode Exchange (SNRME), and UA, are also mentioned.
FEP to FEP - SDLC without Router
This example demonstrates basic FEP-to-FEP over SDLC. If echo is set ON on both sides, the primary network node sends the @snrm(e) and the secondary responds with the address (@) + 0x80. The address the primary node uses is the relative offset of the station in the NCP gen deck. This randomizes the SDLC addresses used so any line swap can be detected.
The flow between the two FEPs is displayed:
actlnk->
dsr comes up
will answer anything with a dm
<+rsp
contact->
sends xid, pri+sec+echo->
<-sends xid pri+sec+echo
....
agree on tg number, tg active, etc.
<-sends xid with byte 19 set to 07
@snrm(e)------------>
<----------------@+x'80'ua
@r/r---------------->
<----------------@+x'80'r/r
<-contacted
contacted->
iframes
...
FEP to ICA - SDLC without Router
This example demonstrates FEP-to-VTAM Integrated Communications Adapter (ICA). If echo is not set on both sides, the primary node sends a ffsnrm(e) and the secondary responds with address(@)ua. The address is usually the subarea address.
The flow between the FEP and ICA is displayed:
actlnk->
dsr comes up
will answer anything with a dm
<+rsp
contact->
sends xid, pri+sec+echo->
<---sends xid pri+sec
agree on tg number, tg active, etc.
<-sends xid with byte 19 set to 07
ffsnrm(e)------------->
<-------------------sa@ua
@r/r---------------->
<-----------------@r/r
<-contacted
contacted->
iframes
...
FEP to FEP - TR to SDLC with TR FEP with Highest Subarea Number
This example adds a Token Ring-attached FEP to the network. The Token Ring-attached FEP sets the echo bit. In this diagram, the Token Ring FEP is the primary node or highest subarea number. Because the SDLC-attached router becomes primary, it can use any polling SDLC address ranging from 0x01 - 7e. There is no need to count lines on the SDLC-attached FEP NCP gen deck.
The flow between the two FEPs is displayed:
contact->
sends xid, pri+sec+echo------------------>
<-------------------sends xid pri+sec+echo
agree on tg number, tg active, and so on
<-sends xid with byte 19 set to 07
sabme->
-------dlsw contact>
@snrm--->
<--@+0x80ua
<-----dlsw contacted
<-----ua
r/r---->
<----r/r
<--contacted
@r/r------>
<-----@+0x80ua
contacted-->
FEP to FEP - TR to SDLC with SDLC FEP with Highest Subarea Number
In this example, the Token Ring-attached FEP becomes the secondary device or lowest subarea number. Therefore, the SDLC-attached router is secondary as well. If you are not using the seconly option, you must count the lines at the NCP gen deck of SDLC-attached FEP and use that count as the SDLC address configured in the router. This is not the recommended method. Refer to CIP to SDLC FEP - Using seconly Option for an example using seconly.
The flow between the two FEPs is displayed:
contact->
sends xid, pri+sec+echo------------------>
<-------------------sends xid pri+sec+echo
agree on tg number, tg active, etc.
<--@snrm
<-------dlsw contact
<----sabme
ua------>
dlsw contacted-------->
<-----IOS waits for the next snrm
<-----@snrm
@+0x80ua
<----r/r
r/r--->
<-contacted <----@r/r
@+0x80-r/r
contacted
CIP to SDLC FEP - with CIP with Highest Subarea Number
In this example, the Token-Ring FEP is replaced with a CIP.
Note: This works the same with an ICA (see FEP to ICA - SDLC without Router). Echo defeat support is OFF.
The flow between the CIP and FEP is displayed:
contact->
sends xid, pri+sec+echo------------------>
<-------------------sends xid pri+sec+echo
agree on tg number, tg active, etc.
sabme---->
------dlsw contacted-->
@snrm->
<--ffdm
Because echo is OFF, the SDLC-attached FEP is expecting a FFSNRM, while the router just sends @SNRM. This causes the SDLC-attached FEP to respond with a FF disconnect mode (DM). Therefore, in this case, communication is not established. Refer to CIP to SDLC FEP - Using seconly Option to establish communication.
CIP to SDLC FEP - with SDLC FEP with Highest Subarea Number
This example is the same as the previous one, but the FEP is now in a higher subarea.
The flow between the CIP and FEP is displayed:
contact->
sends xid, pri+sec+echo------------------>
<-------------------sends xid pri+sec+echo
agree on tg number, tg active, etc.
<----ffsnrm
<-----dlsw contact
<---sabme
ua----->
dlsw contacted------->
<!---IOS waits for the next snrm <-- ffsnrm
@ua------>
....
CIP to SDLC FEP - Using seconly Option
This example adds the SECONLY keyword. This keyword eliminates the need for counting PU4 lines on the NCP to determine the correct polling address. Because the SDLC-attached router is always secondary when seconly is coded, the polling address is determined by the router. Remember that echo is OFF when using this option.
Note: To perform configuration tasks easily, it is always recommended to use the seconly option. The seconly option can be used in any of the scenarios described in this section.
The flow between the CIP and FEP is displayed:
contact->
sends xid, pri+sec+echo------->xid, sec---->
<---sends xid pri+sec+echo
<-----xid pri
agree on tg number, tg active, etc.
<----ffsnrm
<-----dlsw contact
<---sabme
ua----->
dlsw contacted------->
<!---IOS waits for the next snrm <-- ffsnrm
@ua------>
....
Sample Configurations
In this section, you are presented with the information to configure the features described in this document.
This document uses these sample configurations:
-
Router Sample Configurations:
-
DLSw Remote Peer Connection (Two Routers)
-
DLSw Local-Switching Connection (One Router)
-
-
NCP and VTAM Sample Configurations:
-
FEP SDLC
-
FEP Token Ring Subarea
-
VTAM XCA Subarea Major Node
-
Note: Use the Command Lookup Tool ( registered customers only) to find more information on the commands used in this document.
DLSw Remote Peer Connection (Two Routers)
The most common router configuration mistake is to use the wrong SDLC partner MAC address. In all the sample router configurations, 4000.1111.0020 matches the CIP adapter 0 MAC address for CIP case, and matches the FEP tic LOCADD value for the subarea Token Ring case.
Note: All configurations are not exact and can be manipulated where needed, for example: nrzi, clockrate, mtu, sdlc n1.
This scenario shows two DLSw+ routers connected by an IP network. Each one of these routers has a connection to a FEP. One side is attached through a Token Ring interface and the other via an SDLC line.
SDLC-Attached FEP to LAN-Attached FEP Across an IP Cloud using DLSw+
|
Router A |
|---|
source-bridge ring-group 1111 dlsw local-peer peer-id 10.1.1.1 dlsw remote-peer 0 tcp 10.2.2.2 interface token ring 6/0 ring-speed 16 source-bridge 2 1 1111 |
|
Router B |
|---|
dlsw local-peer peer-id 10.2.2.2 dlsw remote-peer 0 tcp 10.1.1.1 interface Serial1 description Sdlc configuration PU4/PU4 mtu 6000 no ip address encapsulation sdlc no keepalive clockrate 9600 sdlc vmac 4000.3745.0000 sdlc N1 48016 sdlc address 04 seconly sdlc partner 4000.1111.0020 04 sdlc dlsw 4 |
This scenario shows two DLSw+ routers connected by an IP network. Router A has a direct channel connection to the mainframe using a CIP/CPA card. Router B has an SDLC connection to a FEP.
SDLC-Attached FEP to a Cisco CIP Mainframe-Attached Router Across an IP cloud Using DLSw+
|
Router A |
|---|
source-bridge ring-group 1111 dlsw local-peer peer-id 10.1.1.1 dlsw remote-peer 0 tcp 10.2.2.2 interface Channel5/0 csna 0100 20 interface Channel5/2 lan TokenRing 0 source-bridge 1 1 1111 adapter 0 4000.1111.0020 |
|
Router B |
|---|
dlsw local-peer peer-id 10.2.2.2 dlsw remote-peer 0 tcp 10.1.1.1 interface Serial1 description Sdlc configuration PU4/PU4 mtu 6000 no ip address encapsulation sdlc no keepalive clockrate 9600 sdlc vmac 4000.3745.0000 sdlc N1 48016 sdlc address 04 seconly sdlc partner 4000.1111.0020 04 sdlc dlsw 4 |
DLSw Local-Switching Connection (One Router)
This scenario shows two FEPs attached to the same router. One FEP connects via a Token Ring interface and the other one via an SDLC line. The router is configured for DLSw+ local-swiching (no dlsw remote-peer configured).
SDLC-Attached FEP to LAN-Attached FEP Using DLSw+ Local Switching
|
Router A |
|---|
source-bridge ring-group 1111 dlsw local-peer interface Serial1/0 description Sdlc configuration PU4/PU4 mtu 6000 no ip address encapsulation sdlc no keepalive clockrate 9600 sdlc vmac 4000.3745.0000 sdlc N1 48016 sdlc address 04 seconly sdlc partner 4000.1111.0020 04 sdlc dlsw 4 interface token ring 6/0 ring-speed 16 source-bridge 2 1 1111 |
This scenario shows a CIP-attached mainframe and a SDLC-attached FEP connecting into the same router. The router is configured for DLSw+ local-swiching (no dlsw remote-peer configured).
SDLC-Attached FEP to CIP Using DLSw+ Local Switching
|
Router A |
|---|
source-bridge ring-group 1111 dlsw local-peer interface Serial1/0 description Sdlc configuration PU4/PU4 mtu 6000 no ip address encapsulation sdlc no keepalive clockrate 9600 sdlc vmac 4000.3745.0000 sdlc N1 48016 sdlc address 04 seconly sdlc partner 4000.1111.0020 04 sdlc dlsw 4 interface Channel5/0 csna 0100 20 interface Channel5/2 lan TokenRing 0 source-bridge 1 1 1111 adapter 0 4000.1111.0020 |
NCP and VTAM Sample Configurations
The most common NCP/VTAM configuration mistake is to use the wrong MAC address when defining the PU4 MAC address of the remote. In the NCP/VTAM sample configurations, notice the PU ADDR field of the NCP and the XCA MACADDR field of the VTAM. Both are pointing to the value 4000.3745.0004. This number is equal to the sdlc vmac MAC configured in the router (4000.3745.0000) plus the configured sdlc address (0x04). Most users initially point to the sdlc vmac value and fail to add the sdlc address.
Note: Remember that the sdlc address is used to modify the last byte of the sdlc vmac.
FEP SDLC
|
FEP SDLC |
|---|
00084 *******************************************************************" 00085 SDLCPRIM SDLCST GROUP=INNPRIM, SDLC STATEMENTS FOR INN * 00086 MAXOUT=7, * 00087 MODE=PRIMARY, * 00088 PASSLIM=254, * 00089 RETRIES=(5,2,5), * 00090 SERVLIM=4 00091 SDLCSEC SDLCST GROUP=INNSEC, SDLC STATEMENTS FOR INN * 00092 MAXOUT=7, * 00093 MODE=SECONDARY, * 00094 PASSLIM=254, * 00095 RETRIES=(5,2,5) 00139 ***********************************************************LV910409 00140 * LV910409 00141 * GROUP STATEMENT FOR INN STATIONS LV910409 00142 * LV910409 00143 ***********************************************************LV910409 00144 INNPRIM GROUP DIAL=NO, * 00145 LNCTL=SDLC, * 00146 MODE=PRIMARY, * 00147 REPLYTO=60 00148 INNSEC GROUP DIAL=NO, * 00149 LNCTL=SDLC, * 00150 MODE=SECONDARY, * 00151 REPLYTO=NONE 00286 *******************************************************************" 00287 * *" 00288 * GROUP MACROS FOR INN CONNECTIONS *" 00289 * *" 00290 *******************************************************************" 00291 GRPINN GROUP ACTIVTO=60, SEC WAIT FOR PRIM * 00292 ANS=CONT, * 00293 CLOCKNG=EXT, * 00294 DATRATE=HIGH, * 00295 DIAL=NO, * 00296 DUPLEX=FULL, * 00297 IRETRY=NO, * 00298 ISTATUS=ACTIVE, * 00299 LNCTL=SDLC, * 00300 MAXOUT=7, * 00301 MAXPU=1, * 00302 MONLINK=YES, * 00303 NEWSYNC=NO, * 00304 NRZI=NO, * 00305 PASSLIM=254, * 00306 PAUSE=0.2, * 00307 REPLYTO=1, * 00308 RETRIES=(3,1,3), * 00309 SDLCST=(SDLCPRIM,SDLCSEC), * 00310 SERVLIM=255, * 00311 TGN=2, * 00312 TRANSFR=27, * 00313 TYPE=NCP 00314 *" 00315 ERNLN012 LINE ADDRESS=012,ISTATUS=ACTIVE 00316 ERNPU012 PU PUTYPE=4 00317 *" |
FEP Token Ring Subarea
|
FEP Token Ring Subarea |
|---|
******************************************************** 06260099
* SDLCST STATEMENT FOR SDLC CONNECTED NCP-NCP LINKS * 06270099
******************************************************** 06280099
N46DPRIS SDLCST GROUP=N46DPRIG, * X06290099
MAXOUT=7, * FRAMES RECIEVED BEFORE RESPONSX06300099
MODE=PRIMARY, * PRIMARY MODE X06310099
PASSLIM=254, * MAXIMUM # OF PIUS SENT TO PU X06320099
RETRIES=(3,2,30), * RETRIES X06330099
SERVLIM=4 * REGULAR / SPECIAL SCANS 06340099
N46DSECS SDLCST GROUP=N46DSECG, X06350099
MAXOUT=7, X06360099
MODE=SECONDARY, X06370099
PASSLIM=254, X06380099
RETRIES=3 06390099
*********************************************************************** 45570099
* GROUP STATEMENTS FOR INN LINKS * 45580099
*********************************************************************** 45590099
N46DPRIG GROUP DIAL=NO, * NON-SW LINE CONTROL * X45600099
LNCTL=SDLC, * SDLC PROTOCOLS * X45610099
MODE=PRIMARY, * PRIMARY MODE * X45620099
REPLYTO=1 * TIMEOUT IF NO MSG RESP WITHIN 10 SEC* 45630099
* REQUIRED FOR REMOTE LOADS 45640099
N46DSECG GROUP ACTIVTO=180, * TIMEOUT IF NO CONTACT FOR 7 MIN * X45650099
DIAL=NO, * NON-SW LINE CONTROL * X45660099
LNCTL=SDLC, * SDLC PROTOCOLS * X45670099
MODE=SECONDARY, * SECONDARY MODE * X45680099
REPLYTO=NONE * DONT TIMEOUT - SECONDARY END ONLY * 45690099
*********************************************************************** 46680099
* TOKEN RING PHYSICAL DEFINTIONS * 46690099
*********************************************************************** 46700099
N46DPTR1 GROUP ECLTYPE=(PHYSICAL,SUBAREA), X46710099
NPACOLL=YES 46720099
N46LYA LINE ADDRESS=(1088,FULL), TIC ADDRESS X46730099
ISTATUS=ACTIVE, X46743099
PORTADD=1, X46760099
MAXTSL=1108, X46770099
RCVBUFC=4095, MAX FROM RING TO NCP X46780099
LOCADD=400011110020 3745 ADDRESS ON RING 46790099
N46PYA PU ANS=CONT 46800099
N46UYA LU ISTATUS=INACTIVE DUMMY LU 46810099
* STATOPT=OMIT 46820099
*********************************************************************** 46829999
* TOKEN RING LOGICAL DEFINITIONS - SUBAREA LINKS * 46830099
*********************************************************************** 46830199
N46DLTR1 GROUP ECLTYPE=(LOGICAL,SUBAREA), * LOGICAL SUBAREA GROUP * X46830299
ISTATUS=INACTIVE, X46830399
NPACOLL=YES, X46830499
PHYSRSC=N46PYA 46830699
N46LXA47 LINE SDLCST=(N46DPRIS,N46DSECS),ISTATUS=ACTIVE 46830799
N46PXA47 PU ADDR=04400037450004 46830999
|
VTAM XCA Subarea Major Node
|
VTAM XCA Subarea Major Node |
|---|
00001 VBUILD TYPE=XCA 00002 SUBAPRT PORT ADAPNO=0, * 00003 CUADDR=120, * 00004 MEDIUM=RING, * 00005 SAPADDR=4, * 00006 TIMER=30 00007 SUBAGRP GROUP DIAL=NO 00008 SUBALN LINE USER=SNA 00009 SUBAPU PU MACADDR=400037450004, * 00010 PUTYPE=4, * 00011 SAPADDR=4, * 00012 SUBAREA=63, * 00013 TGN=2 |
Verify
There is currently no verification procedure available for this configuration.
Troubleshoot
This section provides information to troubleshoot your configuration.
Troubleshooting Procedure
Follow these instructions to troubleshoot your configuration. Refer to Troubleshooting DLSw for additional information on troubleshooting.
-
Ensure the sdlc partner MAC address configured in the router matches the CIP adapter MAC address (if using CIP), or the FEP TIC MAC address.
-
Verify that the PU4 MAC address configured in the XCA major node definition (if using CIP) or in the TIC logical definitions, matches the SDLC-attached router VMAC + SDLC address. Remember that the SDLC address is used to modify the last byte of the SDLC VMAC.
-
Issue the router command show interface serial x/y to display the statistics related to the SDLC interface. Verify that input and output packets are being recorded there. If any of the counters is equal to zero, check the HDX/FDX and NRZ/NRZI settings. By default, IOS defaults to NRZ encoding and Full duplex.
-
If the DLSw+ circuit fails to connect, issue the command show dlsw reachability to verify that the routers have the correct information about the location of the MAC addresses involved. If the SDLC VMAC address does not appear, check if the SDLC interface is UP and that input and output packets counters are incrementing. If the CIP adapter or FEP TIC MAC address is missing from the reachability table, perform standard CIP CSNA troubleshooting (if using CIP), or check the physical status of the TIC (if using FEP Token Ring subarea). Remember that the reachability information is only used during circuit setup and never used afterwards. Therefore, you can end up in a situation where the reachability table is empty, but there are working DLSw+ circuits. Refer to Troubleshooting DLSw Reachability for more information.
-
If the XID is sent on only one side, verify that both sides are pending contact, such as PCTD1 or PCTD2.
-
If both sides are continously sending XIDs, check the TG active bit.
-
If the SNRM is being answered with a DM, the FEP sends a SNRME, when it can be sending a SNRM. A router doing local ack for an sdlc interface does not accept an incoming SNRME (which attempts to set the window size to 128). This is not supported, so verify that the MAXOUT parameter is not greater than seven (7).
-
Another case where the router can send a DM is when the FEP sends ffsnrm but is sending @snrm instead. If echo is OFF, the router is expecting to get ffsnrm.
-
Also, check XID2 error byte (byte 18) for non 0 values. Bytes 18 and 19 are easy to spot; just look for the load module name as it is at byte 20.
-
In the case where the sdlc router receives snrm, IOS waits for the next snrm after the dlsw contact/contacted has completed. If NCP has a replyto code > 40s, the IOS sdlc code times out the connection. Replyto must be coded between 1 and 3 seconds.
-
Issue the command show dlsw circuit to verify the status of the connection. Look for STATE equal to CONNECTED. If using only one router, such as DLSw+ Local Switching, issue the command show dlsw local. Refer to Troubleshooting DLSw+ Circuit Connectivity for more information.
NetPro Discussion Forums - Featured Conversations
| NetPro Discussion Forums - Featured Conversations for IBM |
| Network Infrastructure: Enterprise Data Centers |
Related Information
| Updated: Jun 07, 2006 | Document ID: 12357 |