AS400 Multiprotocol

IBM
AS/400 in Multiprotocol Networks

Mick Lugton, Jim Dacruz, Marc Willems
International Technical Support Organization http://www.redbooks.ibm.com
SG24-4522-01
IBM
International Technical Support Organization AS/400 in Multiprotocol Networks January 1999
SG24-4522-01
Take Note! Before using this information and the product it supports, be sure to read the general information in Appendix A, Special Notices on page 559.
Second Edition (January 1999)

This edition applies to the licensed program IBM Operating System/400 (Program 5769-SS1), Version 4 Release 2. Comments may be addressed to: IBM Corporation, International Technical Support Organization Dept. HZ8 Building 678 P.O. Box 12195 Research Triangle Park, NC 27709-2195 When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way it believes appropriate without incurring any obligation to you. Copyright International Business Machines Corporation 1996 1999. All rights reserved. Note to U.S. Government Users Documentation related to restricted rights Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Preface . . . . . . . . . . . . . . . . The Team That Wrote This Redbook . . . . . . . . Comments Welcome
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ix ix x
Part 1. Part 1 - Introduction
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 3 4 5 6 6 7 7 8 9 9 11 12 14 14 15 16 16 17 17 18 18 19 22 23 25 26 26 27 28 29 29 29 31 31 33 33 34 34 34 35 37 38 40
Chapter 1. Why Multiprotocol Networks . 1.1 How Multiple Protocols Arise . . . . . 1.2 Multiprotocol Networks Using Routers . . . . . . . . 1.2.1 What Are Routers? 1.2.2 Benefits of Routers . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 2. Networking Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Why Different Protocols? 2.2 SNA (Systems Network Architecture) . . . . . . . . . . . . 2.2.1 Subarea SNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 APPN (Advanced Peer-to-Peer Networking) 2.2.3 High Performance Routing . . . . . . . . . . . . . . . . 2.2.4 Rapid Transport Protocol (RTP) . . . . . . . . . . . . . 2.2.5 Automatic Network Routing (ANR) . . . . . . . . . . . 2.3 TCP/IP (Transmission Control Protocol/Internet Protocol) . . . . . . . . . . . . . . . 2.4 IPX (Internet Packet Exchange) . . . . . . 2.5 NetBIOS (Network Basic Input/Output System) 2.6 Link Layer Protocols . . . . . . . . . . . . . . . . . . . . . . 2.6.1 Local Area Network Link Layer Protocols . . . . . . . 2.6.2 Wide Area Network Link Layer Protocols . . . . . . . 2.7 Bridging versus Routing . . . . . . . . . . . . . . . . . . . . 2.7.1 Overview of Bridging . . . . . . . . . . . . . . . . . . . 2.7.2 Bridging Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.7.3 Source Route Transparent Bridging (SRT) . . . . 2.7.4 Source Route - Translational Bridge (SR-TB) . . . . . . . . . . . . . . . . . . . 2.7.5 Overview of Routing . . . . . . . . . . 2.8 Routable versus Nonroutable Protocols 2.8.1 TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.2 NetBIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.3 Subarea SNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8.4 APPN . . . . . . . . . . . . . . . . . . . . 2.8.5 Protocol Summary 2.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 3. Router Technology . . . . . . . . . . . . . . 3.1 How Do Routers Work? 3.1.1 IP RIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 OSPF . 3.1.3 Summary of OSPF versus RIP 3.2 Data Link Switching (DLSw) Overview 3.2.1 What Is DLSw? . . . . . . . . . . . . . . . . . 3.2.2 DLSw Implementation . . . . . . . 3.2.3 Problems with DLSw . . . . . . 3.2.4 DLSw versus Bridging . . 3.3 Boundary Access Node Function
Copyright IBM Corp. 1996 1999
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii
3.4 SDLC Support . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Comparison between DLSw SDLC and SDLC Relay . . . . . . . . . . . . . . . . . 3.5 IBM Router APPN Support . . . . . . . . . . . . . . 3.5.1 Additional APPN Functions Chapter 4. IBM Router Products . . . . . . . . . . . . . . . . 4.1 The IBM 2216 Nways Multiaccess Connector 4.2 The IBM 2210 Nways Multiprotocol Router . . . . . 4.3 Choosing between the IBM 2216 and the IBM 2210 . . . . . . . . . . . . . . . . . 4.4 OEM Router Products 4.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41 42 43 43 45 45 47 49 49 49 51 51 52 54 55 55 55 55 56 56 57 58 59 59 59
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 5. AS/400 Networking Capabilities . . . . . . . . 5.1 AS/400 Networking Support . . . . . . . . . . . . . . . . . . . . . . 5.1.1 AS/400 Communications Hardware . . . . . . . . . . . . . . 5.1.2 Adapters and Interfaces 5.1.3 Network Architecture Support on Link Protocols 5.2 5250 Device Support . . . . . . . . . . . . . . . . . . . 5.2.1 Remote 5X94 Controllers . . . . . . . . . . . . . . . . . . . . . . 5.3 AS/400 Communications Applications . . . . . . . . . . . . . . . . . 5.3.1 APPC Applications . . . . . . . . . . . 5.3.2 AS/400 to S/390 Applications . . . . . . . . . . . . . . . . . . . 5.3.3 TCP/IP Support . . . . . . . . . . . . . . . . . . . . . 5.3.4 OSI Support . . . . . . . . . . . . . . . . . . 5.3.5 NetBIOS Support 5.3.6 IPX Support . . . . . . . . . . . . . . . . . . . . . . 5.4 AS/400 Communications Configuration . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Part 2. Part 2 - Router Scenarios
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65 67 67 71 75 76 76 77 78 80
Chapter 6. Router Configuration Tools . 6.1.1 Graphical Configuration Program 6.1.2 Command Line Interface . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 7. IBM 2210s, IBM 5394 and SDLC Relay . . . . . . . . . . . . . 7.1 Hardware/Software Involved . . . . . . . . . . . . . . . . . . . . . . . 7.2 AS/400 and IBM 5394 Configuration . . . . . . . . . . . . . . . . . . . 7.3 IBM 2210 Router Configuration . . . . . . . . . . . . . . . . . . . . . . 7.3.1 Token-Ring Attached IBM 2210 with Serial SDLC Line - 2210TR . . . . . . . . . . . . . . 7.3.2 Ethernet-Attached IBM 2210 - 2210ETH Chapter 8. 5494 Connectivity Using IBM 2210 APPN . . . . . . . . 8.1 Hardware and Software Involved 8.2 The APPN Network . . . . . . . . . . . . . . . . . 8.2.1 AS/400 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2.2 IBM 5494 Definitions . . . . . . . . . . . . . . . . 8.2.3 Thinkpad Setup . . . . . . . . . . . . . . 8.3 IBM 2210 Configuration . . . . 8.4 Starting and Verifying the Configuration
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85 85 . 87 . 87 . 89 . 91 100 111 117 118 119 119
Chapter 9. IBM 2210 Frame Relay Connectivity to an AS/400 . . . . . . . . . . . . . 9.1 Hardware and Software Involved 9.2 The APPN Network . . . . . . . . . . . . . . . . . . . . . . 9.2.1 AS/400 APPN Definitions . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
9.2.2 IBM 5494 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 9.2.3 Thinkpad Setup 9.3 The TCP/IP Network . . . . . . . . . . . . . . . 9.3.1 AS/400 TCP/IP Definitions . . . . . . . . . 9.3.2 Thinkpad Setup for TCP/IP . . . . . . . . . . . . . . . . 9.3.3 IP Host TCP/IP Configuration . . . . . . . . . . . . . . . . . 9.4 The IPX Network . . . . . . . . . . . 9.4.1 AS/400 IPX Definitions . . . . . . . . . . . . . 9.5 IBM 2210 Configuration . . 9.6 Starting and Verifying the Configurations 9.6.1 Starting and Verifying the APPN Network 9.6.2 Starting and Verifying the TCP/IP Network . 9.6.3 Starting and Verifying the IPX Network
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
122 125 133 133 135 135 136 136 139 160 160 165 167 173 174 175 175 178 180 189 189 190 190 191 193 193 196 197 197 197 215 235 235 239 243 247 248 249 249 254 257 262 262 265 266 266 266 267 267 270 272 272 303
Chapter 10. Multiprotocol Connectivity Using Two Routers 10.1 Hardware and Software Involved . . . . . . . . . . . . 10.2 The APPN Network . . . . . . . . . . . . . . . . . . . . 10.2.1 AS/400 APPN Definitions . . . . . . . . . . . . . . 10.2.2 IBM 5494 Definitions . . . . . . . . . . . . . . . . . 10.2.3 Client Access Setup for SNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 The TCP/IP Network . . . . . . . . . . . . . 10.3.1 AS/400 TCP/IP Definitions . . . . . . . . . . . . . 10.3.2 IP Client Setup for TCP/IP . . . . . . . . . . . 10.3.3 IP Host TCP/IP Configuration 10.3.4 Client Access Setup for TCP/IP . . . . . . . . . . 10.4 The IPX Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.4.1 AS/400 IPX Definitions . . . . . . . . . . . . . . . . . . 10.5 The NetBIOS Network 10.6 Router Definitions . . . . . . . . . . . . . . . . . . . . . 10.6.1 IBM 2216 Configuration . . . . . . . . . . . . . . . 10.6.2 Starting the 2216 Configuration . . . . . . . . . . 10.7 IBM 2210 Configuration . . . . . . . . . . . . . . . . . . 10.8 Starting and Verifying the Configurations . . . . . . . 10.8.1 Starting and Verifying the APPN Network . . . . . . . 10.8.2 Starting and Verifying the TCP/IP Network . . . . . 10.8.3 Starting and Verifying the IPX Network Chapter 11. Multiprotocol Connectivity with Backup 11.1 Hardware and Software Involved . . . . . . . . 11.2 The APPN Network . . . . . . . . . . . . . . . . 11.2.1 AS/400 APPN Definitions (RALYAS4C) . . 11.2.2 AS/400 APPN Definitions (RALYAS4A) . . 11.2.3 IBM 5494 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 The TCP/IP Network . 11.3.1 AS/400 TCP/IP Definitions (RALYAS4C) . 11.3.2 AS/400 TCP/IP Definitions (RALYAS4A) 11.3.3 ThinkpadA Setup for TCP/IP . . . . . . . . 11.3.4 ThinkpadB Setup for TCP/IP . . . . . . . . . . . . . . . 11.3.5 IP Host TCP/IP Configuration 11.4 The IPX Network . . . . . . . . . . . . . . . . . . . . . 11.4.1 AS/400 IPX Definitions (RALYAS4C) . . . 11.4.2 AS/400 IPX Definitions (RALYAS4A) 11.5 Router Definitions . . . . . . . . . . . . . . . . . 11.5.1 IBM 2210A Configuration . . . . . . . . . . 11.5.2 IBM 2210B Configuration . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
11.6 Starting and 11.6.1 Starting 11.6.2 Starting 11.6.3 Starting
Verifying the and Verifying and Verifying and Verifying
Configurations . . . the APPN Network the TCP/IP Network . the IPX Network
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
332 332 338 343 347 348 349 349 352 355 355 357 357 358 359 359 361 363 363 363 379 379 395 395 401 405 411 412 413 413 416 418 421 421 421 435 452 452 459 460 461 461 464 466 470 470 470 485 498 509 509
Chapter 12. Multiprotocol Central Site Connectivity 12.1 Hardware and Software Involved . . . . . . . . 12.2 The APPN Network . . . . . . . . . . . . . . . . 12.2.1 AS/400 APPN Definitions (RALYAS4C) . . 12.2.2 AS/400 APPN Definitions (RALYAS4A) . . . . . . . . . . . . . . . . . 12.3 The TCP/IP Network . 12.3.1 AS/400 TCP/IP Definitions (RALYAS4C) . 12.3.2 AS/400 TCP/IP Definitions (RALYAS4A) . . . . . . . . . 12.3.3 IP Client Setup for TCP/IP . . . . . . . 12.3.4 IP Host TCP/IP Configuration 12.4 The IPX Network . . . . . . . . . . . . . . . . . . . . . 12.4.1 AS/400 IPX Definitions (RALYAS4C) . . . 12.4.2 AS/400 IPX Definitions (RALYAS4A) 12.5 Router Definitions . . . . . . . . . . . . . . . . . 12.5.1 2216A Configuration . . . . . . . . . . . . . 12.5.2 Starting the 2216 Configuration . . . . . . 12.5.3 2216B Configuration . . . . . . . . . . . . . 12.5.4 Starting the 2216 Configuration . . . . . . 12.6 Starting and Verifying the Configurations . . . 12.6.1 Starting and Verifying the APPN Network 12.6.2 Starting and Verifying the TCP/IP Network . 12.6.3 Starting and Verifying the IPX Network Chapter 13. APPN/HPR Encapsulation in TCP/IP 13.1 Hardware and Software Involved . . . . . . . 13.2 The APPN Network . . . . . . . . . . . . . . . 13.2.1 AS/400 APPN Definitions (RALYAS4C) . 13.2.2 AS/400 APPN Definitions (RALYAS4A) . 13.2.3 IBM 5494 Definitions . . . . . . . . . . . . 13.3 Router Definitions . . . . . . . . . . . . . . . . 13.3.1 2216A Configuration . . . . . . . . . . . . . . . . . 13.3.2 Starting the 2216 Configuration 13.4 IBM 2210 Configuration . . . . . . . . . . . . . 13.5 Starting and Verifying the Configurations . . 13.5.1 Starting and Verifying the APPN Network Chapter 14. APPN Network Extension . . . . . . . 14.1 Hardware and Software Involved . . . . . . . 14.2 The APPN Network . . . . . . . . . . . . . . . 14.2.1 AS/400 APPN Definitions (RALYAS4C) . 14.2.2 AS/400 APPN Definitions (RALYAS4A) . 14.2.3 IBM 5494 Definitions . . . . . . . . . . . . 14.3 Router Definitions . . . . . . . . . . . . . . . . 14.3.1 2216A Configuration . . . . . . . . . . . . . . . . . 14.3.2 Starting the 2216 Configuration . . . . . . . . . . . . . . 14.4 2210A Configuration . . . . . . . . . . . . . . 14.5 2210B Configuration 14.6 Starting and Verifying the Configurations . . 14.6.1 Starting and Verifying the APPN Network
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vi
Part 3. Additional Considerations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
515 517 518 519 520 520 520 520 521 521 522 522 522 522 523 523 523 523 525 525 526 526 527 528 529 531 532 535 535 535 537 537 537 538 538 538 539 539 540 541 542 543 545 546 547 548 550 553 555 557
Chapter 15. Providing Backup in Router Networks . . . . . . . . . . . . . . 15.1 ISDN Circuit Backup 15.2 Second Telecommunications Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.2.1 IPX . . . . . . . . . . . . . . . . 15.2.2 IP and DLSw . . . . . . . . . . . . . . . . . . . . . 15.2.3 HPR . . . . . . . . . . . . . . . . . . 15.2.4 Summary 15.3 Twin Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.1 IPX 15.3.2 IP . . . . . . . . . . . . . . . . . . . . . . . 15.3.3 Data Link Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15.3.4 HPR 15.4 Summary . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 16. Performance in Router Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1 General Network Performance 16.1.1 Why Network Performance Is Important . . . . . . . . . . . . . . . 16.1.2 General Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.3 Router Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.1.4 SNA Circuit Pacing . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2 IBM 2210/2216 Features 16.2.1 IBM 2210/2216 Bandwidth Reservation (BRS) . . . . . . . . . . . . 16.2.2 MAC Filtering (MCF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2.3 WAN Restoral Feature (WRS) - Dial Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2.4 Dial on Demand . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.2.5 NetBIOS Facilities 16.3 IBM 2210 Performance Scenario - User Response Time versus Batch . . . . . . . . . . . . . . . . . . . . 16.3.1 Setting Bandwidth Reservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3.2 Summary . . . . . . . . . . . . . . . . 16.4 General Points for the IBM 2210 and 2216 Chapter 17. Network Management in Router Networks 17.1 Router Configuration and Maintenance . . . . . . . . . . . . . . . . . . 17.1.1 Router Configuration . . . . . . . . . . . . 17.1.2 Software Maintenance 17.2 Router Operation and Problem Determination . 17.2.1 Logging on to a Router . . . . . . . . . . . . 17.2.2 Operating the IBM 2210 and 2216 . . . . . . 17.3 Network Monitoring . . . . . . . . . . . . . . . . . 17.4 Summary . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 18. AS/400 and Printing in a Multiprotocol Network . . . . . . 18.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18.2 Migrating the Current Environment . . . . . . . . . . . . . . . . . . . 18.3 AS/400 and Printer Data Streams 18.4 AS/400 as Print Server . . . . . . . . . . . . . . . . . . . . . . . . . . 18.5 AS/400 Printer Support . . . . . . . . . . . . . . . . . . . . . . . . . . 18.5.1 Printers Attached to a Local or Remote Workstation Controller . . . . . . . . . . . . . . . . . . . . . . . 18.5.2 LAN-Attached Printers . . . . . . . . . . . . . . . . 18.5.3 Printers Attached to Workstations 18.5.4 PSF/2, PSF/6000 and AS/400 . . . . . . . . . . . . . . . . . . . . 18.5.5 Print Output to Printers Controlled by Other Systems . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
vii
Appendix A. Special Notices
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
559 561 561 561 561 563 564 565 567
Appendix B. Related Publications . . . . . . . . . . . . . . . . B.1 International Technical Support Organization Publications B.2 Redbooks on CD-ROMs . . . . . . . . . . . . . . . . . . . . B.3 Other Publications . . . . . . . . . . . . . . . . . . . . . . . How to Get ITSO Redbooks . IBM Redbook Fax Order Form Index
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ITSO Redbook Evaluation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii
Preface
This document addresses the growing trend of multiprotocol networks from an AS/400 perspective. The AS/400 is found more and more in mixed protocol and system environments where interoperability is a major requirement. As networking moves to multiprotocol wide area backbones - supporting all the protocols required by today s variety of applications and systems - the AS/400 is found communicating across these backbones. This redbook will help you to understand the concepts of this new multiprotocol environment in which your AS/400 system resides, and how easily the AS/400 fits in. In an AS/400 dominated situation, understanding the concepts of multiprotocol networking helps you decide what direction the backbone should take, especially as the available options increase. This redbook should help to meet these different needs.
The Team That Wrote This Redbook

This redbook was produced by a team of specialists from around the world working at the International Technical Support Organization, Raleigh Center. Mick Lugton is a Systems Engineer at the International Technical Support Organization, Raleigh Center. He writes extensively and teaches IBM classes worldwide on all areas of AS/400 cross-platform connectivity and systems management. Before joining the ITSO 4 years ago, Mick worked in the AS/400 Business Unit, IBM UK as a Networking Specialist. Jim Dacruz is a Networking Specialist in the UK. He has 10 years of experience in the networking field. He has worked at IBM for 24 years. His areas of expertise include 221X routers and LAN PD. He has written extensively on multiprotocol networking. Marc Willems is a Systems Engineer in Belgium. He has 10 years of experience in S/3x, PC and AS/400. He has worked at IBM for 22 years. His areas of expertise include AS/400 communications and connectivity. He has written extensively on AS/400 APPN/HPR and AS/400 TCP/IP. The authors of the first edition of this redbook were: Barry Hesk IBM United Kingdom Stephan Imhof IBM Switzerland Mary Moore IBM United Kingdom
ix
Comments Welcome
Your comments are important to us! We want our redbooks to be as helpful as possible. Please send us your comments about this or other redbooks in one of the following ways:
Fax the evaluation form found in ITSO Redbook Evaluation on page 567 to the fax number shown on the form. Use the online evaluation form found at http://www.redbooks.ibm.com/ Send your comments in an Internet note to redbook@us.ibm.com
Part 1. Part 1 - Introduction

In Part 1 we introduce the world of multiprotocol networking. We start by explaining why networks have to support multiple protocols. We then give a brief introduction to the four most commonly found protocols and explain the functions provided by today s bridges and routers. Lastly, we provide some relevant product information on IBM router products and the AS/400.
Chapter 1. Why Multiprotocol Networks

This chapter explains the move from a classic SNA-based AS/400-oriented network to a multiprotocol network. It is addressed to AS/400 and networking specialists. Workstations communicating with an AS/400, locally or remotely, typically use the SNA protocol to exchange data. The remote workstations can be PCs or IBM 5494 Remote Workstation Controllers, which communicate, for example, via a token-ring LAN or a WAN connection with their host, the AS/400.
Figure 1. Classic AS/400 Networking Environment
New user requirements may need networking solutions which are not AS/400 based and require different network protocols to SNA. This can be, for instance, a NetWare LAN server which uses primarily IPX as its protocol. TCP/IP is another often required protocol used to communicate with systems that do not use SNA, especially UNIX-based systems. The application that meets user requirements should dictate the network protocol. Running a single protocol in a network has some advantages. However, today s popular network applications use different protocols.
These requirements lead us into a multiprotocol environment, and the question comes up as to how can we support different protocols via the same physical network.
1.1 How Multiple Protocols Arise

Traditionally, one site may have an AS/400-based application running and users at remote sites can access it by means of a remote IBM 5494 workstation controller over a wide area link. At the main site, another user requirement may have been satisfied by a NetWare LAN server solution. This means we have two protocols in use, SNA and IPX. At the remote site there may also be a UNIX system running another application. UNIX systems mainly use TCP/IP-based network applications.
Figure 2. Different Applications Require Different Protocols
In this scenario, both the LAN-attached PCs at the main site and the PCs at the remote site now require access to both the AS/400 and the NetWare LAN server. The UNIX workstations will use TCP/IP to communicate with each other and with the AS/400. The network has to support SNA, TCP/IP and IPX protocols. Nowadays, users need access to all systems and applications and do not want to be restricted by protocol and logistics. As the workplace changes, the evolving network must provide access to everything.
Multiple network protocols can coexist in a LAN environment. However, a WAN connection and the system or controller acting as gateway often only support a single protocol. In our scenario, the IBM 5494 is an SNA device. This means it is unable to forward TCP/IP or IPX. In the next section, we look at a solution for transporting all of these protocols over a wide area connection between the local and remote sites.
1.2 Multiprotocol Networks Using Routers

This is the point where a company s network has to become a multiprotocol network and where routers will take over the role of a gateway between the LAN and WAN environment. This means that the AS/400 and the user devices (like the IBM 5494) move one step back, and other devices (networking devices such as routers) take over the task of providing the backbone. One solution to the situation in Figure 2 on page 4 is shown in Figure 3.
Figure 3. Multiprotocol Router Network with AS/400 and I B M 5494
Chapter 1. Why Multiprotocol Networks
1.2.1 What Are Routers?

Routers are networking devices usually equipped with a LAN and a WAN adapter. A pair of routers accomplish the interchange of data between two distributed LANs. To this extent, bridges perform the same level of service. However, bridges are not protocol-sensitive and forward all traffic between LAN environments. To control and reduce this considerable amount of traffic, more sensitive networking devices called routers were introduced. Routers are configured to forward data for specified remote networks only. Routers make this decision for each piece of data sent based on the target address included in the header of the data. The way the various protocols, like TCP/IP, SNA, and IPX, communicate differs. Only connectionless protocols, like TCP/IP, include the network addresses with each frame and piece of data sent allowing the router to selectively forward data. Connection-oriented protocols, like SNA, do not include the destination address with each frame exchanged. Consequently, SNA is not routable in the sense of the so-called multiprotocol routers. This means multiprotocol routers are only able to handle a limited set of network protocols, and different methods have to be used to forward non-routable protocols, such as SNA and NetBIOS. Remember that connectionless protocols route and connection-oriented protocols do not. Today s routers have function in addition to be being able to route routable protocols. For example, an IBM 2210 Nways Multiprotocol Router or IBM 2216 Nways Multiaccess Connector offers the following four different categories of functions:

Bridging token-ring and Ethernet traffic Routing protocols like TCP/IP and IPX Data link switching (DLSw) of SNA and NetBIOS Acting as an APPN network node
TCP/IP and IPX are typically routed natively over the multiprotocol router network. NetBIOS and SNA, however, must be encapsulated in TCP/IP frames and transmitted using TCP/IP protocols. This encapsulation and the additional control data (headers) represent an overhead. Hence, when changing from a pure SNA network to a multiprotocol router network, migration will not provide better performance. Networking protocols and router technologies are discussed in Chapter 2, Networking Technologies on page 7 and Chapter 3, Router Technology on page 31.
1.2.2 Benefits of Routers
Routers accomplish the sharing of various network protocols over the same physical link. Routers allow selective forwarding of protocol data based on network address information. The TCP/IP nature of multiprotocol networks allows non-disruptive connections and easy switching to alternate routes.
Chapter 2. Networking Technologies

This chapter presents an overview of networking technologies by concentrating on the following areas:

Protocols Bridging and routing Routable and non-routable protocols
We will start by looking at four of the major protocols in existence today: SNA (including APPN), TCP/IP, IPX and NetBIOS. We will look at each in turn, describing the key points and summarizing their respective strengths and weaknesses. We will then move on to a discussion of bridging and routing, summarizing each, and describing situations where one should be used in preference to the other. Finally, we close the chapter by looking again at our protocols and describing which can be routed and which cannot.
2.1 Why Different Protocols?

The first question is, why have support for different protocols. The answer to this question is that it all comes down to the choice of application and the protocol that it has been written to use. Certain applications use certain protocols. For example, IBM Client Access/400 uses SNA, TELNET uses TCP/IP and Novell NetWare uses IPX. If an environment has a mixture of applications, then the network must be able to support the mixture of protocols required by these applications. The following table describes the protocols that are supported by many of the common application platforms available today:
Table 1. Common Applications and Protocols Application Novell NetWare IBM LAN Server Microsoft LAN Manager IBM Client Access/400 eNetwork Communications Server for OS/2 and Windows, Windows 95 and Windows NT IBM PC/3270 TELNET FTP (File Transfer Protocol) SNMP (Network Management) SMTP (Mail Protocol) NFS (Network File System) Lotus Notes Lotus CC: Mail Protocol IPX NetBIOS NetBIOS SNA,IP or IPX SNA,IP or IPX SNA,IP or IPX TCP/IP TCP/IP TCP/IP TCP/IP TCP/IP TCP/IP, NetBIOS or SNA TCP/IP or SNA
2.2 SNA (Systems Network Architecture)

Systems Network Architecture (SNA) was developed by IBM in the early 1970s and rapidly gained acceptance as the way of networking IBM host systems and allowing access to them from terminal devices. More recently, SNA has evolved to provide support for client/server architectures with APPN playing a particularly prominent role. SNA s main selling points are the very strong support within the protocol for congestion control, flow control and traffic prioritization. This means that the SNA protocol can provide response time guarantees that other protocols will struggle to meet. SNA has also been proven capable of being able to provide stable support for very large and complex networks. SNA is not capable of being routed natively across a router network; rather some encapsulation technique must be used. The best options for carrying SNA on router networks are bridging on local LANs and using data link switching for transport over the wide area. On the negative side, the configuration of SNA can be very time consuming and complex. Configuration of workstations to use SNA services does take far longer than for other comparable protocols. Also, SNA is owned by IBM. Some customers perceive this as a drawback as they move toward open systems. However, we should say that this is not a technical limitation of the architecture.
2.2.1 Subarea SNA

Subarea SNA was the original protocol used to build SNA networks and is still in use today. It relies on a hierarchical rigid structure with all of the network controlling function being handled by the SNA rich mainframes and front-end processors (FEPs). The following diagram represents the hierarchical view of subarea SNA and summarizes the SNA PU types.
Figure 4. Subarea SNA Topology
All SNA sessions are set up and controlled by the SSCP, a special application that runs in the mainframe. Sessions cannot be established between devices without the SSCP being involved.
2.2.2 APPN (Advanced Peer-to-Peer Networking)

Advanced peer-to-peer networking (APPN) provides enhanced functions over SNA node type 2.1. It provides additional support in the SNA transport layers, which enable non-adjacent systems (nodes) to communicate over a single session and appear as if they are attached directly to each other. APPN changes the hierarchical nature of subarea SNA by using a peer-to-peer approach. APPN performs any-to-any routing, without requiring a session between any layer above the transport layer. This is known as intermediate routing. Control of the network is given to peer systems (nodes). This means that APPN sessions can be established between APPN nodes without the mainframe being involved.
The APPN architecture particularly lends itself to client/server applications running on distributed systems that do not need the mainframe in order to be able to communicate.
Figure 5. APPN Network Topology
APPN offers the following advantages over an SNA subarea network:

Better performance during session initiation. Improved performance during network activation by eliminating the SSCP-PU and SSCP-LU control sessions. Reduced system definitions. APPN can dynamically learn about the network topology. Increased availability as the topology is learned dynamically. There is no need to shut down a part of the network to add a new node.
APPN defines the following three types of nodes within a network:

APPN network nodes APPN end nodes Low entry networking (LEN) nodes
An APPN network node (NN) provides directory and routing services for all resources in its domain. A network node s domain consists of the following:
Local resources owned by the node
10
A control point (CP) which manages the node s resources Resources owned by APPN end nodes and LEN nodes that use the services of the network node
An APPN end node (EN) selects a network node to be its network node server and registers its local resources with it. This allows the network node to pass session requests for resources located on the end node. An APPN LEN node is a type 2.1 node without any APPN extensions. It can establish a connection to an end node or network node, but cannot register resources dynamically. All definitions must be predefined on the end node or network node.
2.2.3 High Performance Routing

High Performance Routing (HPR) is an extension to the APPN architecture designed to enhance APPN routing support. Its first aim is to reduce the overhead caused by the session-level error checking which takes place at all intermediate nodes of an APPN-session. HPR achieves this by letting this error checking take place at the beginning and endpoint of the HPR session . By doing this it reduces the latency (the time it takes for data to reach its destination) of the network and the CPU load at the intermediate nodes (and thus allowing more throughput at these routing nodes). While in APPN all NNs over which a session routes play an equally important role in error checking and recovery, in HPR the beginning and end nodes are the only nodes who perform this checking. A second aim of HPR is to allow for non-disruptive path switching in case of failure of one of the intermediate nodes. While in APPN a session has to follow a route which has been determined at the session setup (the NNS of the OLU calculates the RSCV), in HPR the LU-LU flow is over a kind of highway which makes the underlying route (succession of NNs) invisible. The main HPR components by which these aims can be realized are:

Rapid-Transport Protocol (RTP) Automatic Network Routing (ANR)
In an HPR network, the LU-LU sessions take place within RTP connections. These connections can be thought of as pipes. The requirements for a node to be the beginning or endpoint of such a connection are: 1. That it is an APPN end or network node. 2. That it has the ANR functions implemented. 3. That it has the RTP functions implemented. The requirements for a node to be an intermediate node over which such a connection runs are: 1. That it is an APPN Network Node. 2. That it has the ANR functions implemented. An example of how an RTP connection might look can be found in Figure 6 on page 12.
11
Figure 6. An RTP Connection in an HPR Subnet within an APPN Network
The ANR and RTP functions are the main components of HPR. In the next section we provide a brief overview of each of these functions.
2.2.4 Rapid Transport Protocol (RTP)

2.2.4.1 Setup of an RTP Connection
An HPR network consists of a minimum two APPN nodes which have implemented the HPR base functions and the RTP functions. These RTP nodes can: be directly connected to each other (as EN-NN or NN-NN), belong to the same connection network (CN), or they can reach each other by following a route of consecutive NNs which belong to the same APPN network and which contain the HPR base and ANR functions. At a minimum, an HPR network consists of two RTP nodes. These can either both be NNs or one is a NN and provides NNSs for the other (which shows an EN image). The second node could be a Branch Extender which is cascaded under the first node. During the XID negotiation prior to the establishment of a CP-CP session, APPN nodes exchange capabilities. It is during this process that a node learns whether it s partner supports RTP. The topology databases (TDBs) are then updated such that they include the level of HPR support for each of the APPN nodes within the network. At session initiation, an RTP capable node receives an RSCV from the network node server (NNS). It then determines whether an RTP connection already exists that corresponds to the RSCV and the class of service (COS) associated with the mode of the session to be established. If yes, this RTP connection will be used to transport the session. If no, (or if the existing RTP connection has
12
reached a maximum number of sessions for that COS and RSCV), the last RTP capable node appearing in the RSCV will be contacted and a negotiation will take place (using the HPR route setup protocol) to determine:
The ANR labels to be followed (the ANR labels relate to the TGs which the route has to follow). The maximum packet size to use to avoid segmentation at the intermediate nodes. Whether multi-link TGs exist along the path. The network control endpoints (NCEs) at each extreme RTP node. An NCE is to an RTP connection what an LFSID is to an APPN session.
2.2.4.2 Network Layer Packets (NLPs)

Once an RTP connection is in place, RTP-capable nodes can send LU-LU sessions over it (assuming it has corresponding COS and RSCV). As multiple sessions can take place over a single RTP connection, a session address has to be assigned to each portion of the session data so that the origin and destination RTP nodes can route the appropriate data to the appropriate LU. An RTP connection transports network layer packets (NLPs). It should be noted however that an RTP capable node can also send ordinary FID2 labeled transmission units or XID3 frames.
Figure 7. Possible Link Frames in an HPR Node
2.2.4.3 End-to-End Error Recovery

By associating a byte sequence number with the first data byte in an NLP (the value of this byte sequence number is equal to the number of databytes already sent on the RTP connection since the setup of that connection plus one), the receiving RTP node can detect whether there are NLPs missing. In case of missing NLPs, the receiving node informs the sending RTP node which byte sequence number was missing. The sending RTP node then has to restart sending all the missing NLPs
13
2.2.4.4 Non-Disruptive Path Switching

Several circumstances can trigger a path switch. When an RTP connection goes down, one or both the RTP nodes set up a new route to be followed by the new RTP connection. To achieve this, a new RSCV is calculated which corresponds to an HPR only path.
2.2.5 Automatic Network Routing (ANR)

When the two RTP nodes are not adjacent, routing of the NLPs is done by intermediate APPN NNs which have at least the ANR option implemented. Every NLP that an ANR node receives is inspected by the ANR function. The first ANR label in the NLP determines which TG the NLP must be routed over. The ANR function then strips the first ANR label and forwards the NLP to the next hop. In contrast to the RTP capable nodes at which the RTP connection ends, an intermediate ANR capable NN doesn t do any route setup, session level error recovery or flow control (error checking does take place at DLC level and the link level error recovery for SDLC and X.25 still takes place). In contrast to the FID2 transmission units used for APPN, the NLPs aren t segmented at the intermediate ANR capable NNs. Also, these nodes don t perform any flow control for RTP connections as they are not aware of the sessions which flow over it.
2.3 TCP/IP (Transmission Control Protocol/Internet Protocol)

TCP/IP was designed and developed by a project sponsored by the US Department of Defense (DoD) during the early to mid 1970s. The protocol was built to support UNIX machines running on local area networks. It was probably the first example of a protocol designed to support client/server architectures. TCP/IP has no concept of hierarchy. Unlike subarea SNA, all hosts are equal. TCP/IP can be carried natively through router networks by almost all router products. The name TCP/IP came from two of its component parts. IP (Internet Protocol) is the name given to the network layer, while TCP (Transmission Control Protocol) is one of the transport layer protocols that can be used. The other common transport protocol that applications can use is the User Datagram Protocol (UDP). Please see Table 1 on page 7. TCP/IP is the protocol that has been used to build the world s largest network, the Internet. Other strengths of TCP/IP are its vendor independence and ease of configuration. TCP/IP is a de facto standard that has been published. Therefore, any vendor can write their own version based upon the published standard. Also, due to the fact that all implementations are written to the same standard, all versions should interoperate. On the negative side, TCP/IP is let down by its poor congestion control, flow control and traffic prioritization. Some simple schemes do exist for each of these, however, they are not as efficient or effective as those employed by comparable protocols (in particular SNA). The lack of proper controls can make it very difficult to guarantee response times over wide area networks. This
14
situation is made even worse by the presence of certain character mode applications (for example, character mode TELNET), which echoes each character across the network as it is typed rather than transferring data in block format (like SNA). Finally, the current addressing structure for TCP/IP is under severe strain with a shortage of available addresses. This problem is being addressed by various groups by expanding the available addressing scheme. TCP/IP addresses, or more accurately IP addresses, are 32-bit numbers usually written as four decimal numbers separated by dots (for example, 9.67.46.225). Each decimal number consists of 8 bits and hence can take any value between 0 and 255. The IP address is broken into two parts, the network portion and the host portion; the point in the address at which this break is made is governed by the subnet mask . Every IP address must be configured with an associated subnet mask. IP addresses must be unique within the IP network.
2.4 IPX (Internet Packet Exchange)

The IPX protocol was developed by Novell from an original specification of the XNS protocol designed by Xerox. IPX and XNS are in fact very similar protocols only differing in a few minor ways. However, the two protocols are not compatible. IPX is the protocol used by Novell NetWare and thus has a very large installed base. IPX, like IP, was originally designed to run on local area networks with some later extensions being added to allow it to communicate over the wide area. As with IP, IPX is capable of being routed natively by almost all router products. Some products also provide the capability of encapsulating IPX within IP. Recent levels of the Novell code also allow servers and requesters to talk IP natively. This option may be used if, for example, you do not want to run native IPX on your routers. As with IP, IPX describes the network layer of the protocol. Another commonly used term is SPX. SPX is actually one of the transport layer protocols and is similar in function to TCP. The main strengths of IPX are its ease of configuration and the very large installed base. Typically, the installation of IPX on a Novell client requires three or four small modules and minimal configuration. The principle drawback of IPX is its poor performance over the wide area. Even with the extensions provided to allow IPX to communicate over the wide area, the protocol does not perform very well. Some work has been done to improve the situation, in particular, with the implementation of IPX packet burst which is mandatory for any WAN connectivity. Even more recently some new IPX standards, namely LIP (Large Internet Packet) and NLSP (Novell Link Services Protocol), should improve performance once implemented. IPX addresses, like IP addresses, consist of two parts: a network portion and a host portion. However, unlike IP addresses, the IPX address separates these addresses completely into a 32-bit network number and a 48-bit host address. Normally, an IPX host will use its LAN adapter address (the MAC address) as its host address. Only IPX servers and routers are configured with the network number. IPX clients broadcast to find their own network number when they are
15
brought up. IPX addresses (network number and host number) must be unique within the IPX network.
2.5 NetBIOS (Network Basic Input/Output System)

NetBIOS was designed jointly by IBM and Microsoft and originally implemented in the IBM LAN Server and Microsoft LAN Manager platforms. Like many other protocols, NetBIOS was only designed to run over local area networks and, as such, cannot be routed natively by any router products. NetBIOS can be transported over wide area connections either by bridging or more recently, data link switching. The move in the industry at present appears to be away from NetBIOS as it cannot be carried natively by router products. See 2.8, Routable versus Nonroutable Protocols on page 26. The positive aspects of NetBIOS are its ease of configuration and good performance over purely local networks. The negative aspects include its lack of routing support and the constant broadcasting which can flood wide area links. With data link switching there are limitations on the size of NetBIOS networks that can be connected together. Bridging is the only suitable solution for very large NetBIOS networks. NetBIOS addressing is based on two concepts, machine names and domain names . The machine name is the name of the NetBIOS resource and is a free format eight-character string. A domain name is a logical collection of NetBIOS resources and is also a free format eight-character string. All NetBIOS names must be unique in the NetBIOS network. Note that a NetBIOS domain is a logical group of NetBIOS machines, that is, it does not specify where those machines should exist. It is not possible to route based upon a NetBIOS domain name.
2.6 Link Layer Protocols

Each of the protocols that we have looked at so far is defined at layer 3 and upwards in the OSI stack. They all make use of separate link layer protocols that govern how the data is transferred between stations. This section briefly covers some of the link layer protocols in common use today. There are basically two groups of link layer protocols, those for transporting data over the wide area and those for transporting data over local area networks. We will look at each in turn.
16
2.6.1 Local Area Network Link Layer Protocols

We start this discussion by looking in detail at the lower three layers of the OSI seven-layer stack.
Table 2. Layers 1 - 3 of the OSI Stack - LANs 3 2 Network Data Link IP, IPX, etc. LLC MAC 1 Physical UTP, STP, etc.
At layer 1 of the OSI stack we have the different cabling (media) options including unshielded twisted pair (UTP) and shielded twisted pair (STP). Layer 2 of the OSI stack is responsible for two tasks: transmission of the data onto the physical media (Media Access Control - MAC), and the establishment of a logical connection between stations (Logical Link Control - LLC). Media Access Control governs the way in which data is transmitted onto the physical medium. In the LAN world, there are many different standards, the most common being IEEE 802.5 (MAC standard for token-ring) and Carrier Sense Multiple Access/Collision Detect, otherwise known as CSMA/CD (the MAC for Ethernet). This layer of the stack contains the required logic to, for example, transmit data onto an Ethernet network. Logical Link Control uses the Media Access Control to provide an end-to-end logical connection between stations. LLC2 provides a connection oriented and reliable session between two end stations on the same LAN. We should note that bridges operate at the MAC layer; that is, they have no knowledge or visibility of LLC sessions.
2.6.2 Wide Area Network Link Layer Protocols

Table 3. Layers 1 - 3 of the OSI Stack - WANs 3 2 1 Network Data Link Physical IP, IPX, etc. Frame Relay, PPP, SDLC X.21, V.35, etc.
At layer 1 (the physical layer) we are again concerned with physical media. Common standards in this area include X.21, V.35 and V.24 (RS232). At layer 2 (the link layer) we are concerned with one basic function: the establishment of a direct connection between two stations over the physical media selected. Again, as with LAN technologies, there are many standards but three common techniques are as follows:

Frame relay Point-to-point Protocol (PPP) SDLC
Frame relay is very similar conceptually to X.25 and provides logical end-to-end connectivity between end devices across a frame relay backbone. This logical
17
end-to-end connection is known as a Data Link Circuit Identifier (DLCI). Multiple DLCIs to different destinations can be configured on the same router port. Point-to-point protocol (PPP) is a level two protocol that defines a direct point-to-point connection between routers. Only a single PPP connection can be configured on a single port. PPP supports most of the common layer three protocols (IP, IPX, Vines, XNS) directly. SDLC is a standard protocol for the interconnection of SNA devices. SDLC only supports SNA.
2.7 Bridging versus Routing

We start this discussion with a presentation of the well known OSI seven-layer stack model of networking as follows:
Table 4. OSI Seven-Layer M o d e l of Networking 7 6 5 4 3 2 1 Application Presentation Gateway Session Transport Network Data Link Physical Routers Bridges Repeaters
2.7.1 Overview of Bridging

Bridges switch packets at layer 2 of the OSI model and allow all protocols connectivity by building one large flat LAN. Bridges do not see the details of the protocols that they are handling as the network layer addresses are not visible to them. Some protocols can only be bridged because they do not have network layer addresses that allow them to be routed. On token-ring networks, Source Route Bridging is used. On Ethernet, it is known as Transparent Bridging. When bridging between token-ring and Ethernet networks, Translational Bridging is used. The major advantages of bridging are the simplicity of the devices, the protocol independence and the fact that no complex management of the bridges is required. Protocol independence means that all protocols can be bridged across the same connection. In fact, in a purely local environment bridging works very well. On the negative side, bridging does have some drawbacks particularly when network connectivity is required over the wide area. Primary amongst these are lack of congestion control and no prioritization of traffic. Because end stations themselves do not have visibility of bridges, the bridge cannot request that end stations slow down in the event of bridge congestion. Even more importantly, because bridges do not have visibility of the protocols they are bridging, they cannot prioritize protocols over one another. This can cause certain time-sensitive protocols such as SNA or NetBIOS to time out due to the delays on slow speed WANs.
18
2.7.2 Bridging Methods

The following are the two primary methods of bridging:

Transparent bridging or spanning tree bridging (STB) Source route bridging (SRB) used in 802.5 LANs
Then, from these two primary methods of bridging, there are other methods as follows:

Source route transparent bridging (SRT) Source route translational bridging (SR-TB)
In the following sections we provide an overview of these bridging methods.
2.7.2.1 Transparent Bridging

A transparent bridge is also called spanning tree bridge (STB). Transparent bridging is normally used to connect IEEE 802.3 segments. It is specified in the ISO 8802-1 standard. Transparent bridging is based on the principle that a sending device can transmit a frame to a receiving device on a LAN network without having any knowledge of the location of, or the path to, that receiving device. Within a network, transparent bridges are responsible for forwarding the frame to the correct destination. The decision on whether or not a frame should be forwarded is based on the MAC sublayer destination address. Transparent bridges achieve this by building and maintaining a filtering database that acts as a forwarding table for received frames. They build their database by copying all frames from the LANs to which they are attached and learning the location of devices by inspecting the MAC sublayer source address in each received frame.
19
Figure 8 illustrates how a transparent bridge will build up its filtering database.
Figure 8. Transparent Bridging
When the bridge receives a frame from device D1 on port A it learns that D1 can be reached via the LAN on port A. Similarly, if a frame arrives from device D7 on port B it learns that D7 can be reached via the LAN on port B. For each new source address the bridge sees on the LANs, it adds an additional entry in its database. In time, a full picture is built up of all the devices on the two LANs and via which port they can be reached. Transparent bridges support and use the spanning tree protocol which ensures a loop-free topology between all the transparent bridges within the network.
2.7.2.2 Source Route Bridging (SRB)

Source route bridging is implemented by IBM and compatible bridge products for use over token-ring LAN segments. Source routing requires a sending device to specify the path that should be taken by a frame across an internetwork rather than allowing the decision to be made by individual bridges. To do this, a sending device must determine the best path to a destination and include it in all frames to that destination. The best path to a destination is found using a discovery process. One implementation of this process is described as follows: A sending device sends a discovery frame to the intended destination device marked single-route broadcast. Bridges in a token-ring internetwork should be configured using the token-ring spanning tree algorithm to permit only one path
20
for single-route broadcast frames between devices. The destination device should therefore receive only a single copy of the discovery frame. The destination device responds to the discovery frame with a discovery response frame marked all-routes broadcast. This will contain the most significant bit (the route information indicator, also called RII) set in the source MAC address field and an entry in the routing information field (RIF). This will initially contain zero in the bridge number field, and the number of the network to which the destination device is attached in the segment number field. The discovery response frame, because it is marked all-routes broadcast, will pass through all bridges on its way back to the original sending device. Each bridge that the frame passes through must insert its bridge number and LAN segment number. Hence, the frames that return to the original sending device contain the routes that they have taken through the bridged internetwork. The routing information field can currently only hold data about seven bridges and eight LAN segments. If a frame is received by a bridge with this field full, it will be discarded. This limits the number of bridge hops in the network to seven, and is consequently the maximum size of source route bridged internetworks. The original sending device, therefore, receives one or more discovery response frames. These frames contain routing control and bridge and LAN segment numbers in their routing information fields. The routing control field indicates the number of bridge/LAN segments in the routing information field and also the maximum frame size that can be supported by the route. The sending device can now select the best route to use through the internetwork to reach the destination device. Current implementations select the route in the first received discovery response frame (the fastest path at the time of the discovery process) although the architecture allows route selection based on other criteria (for example, maximum frame size supported by the route).
21
Figure 9 shows how the routing information field in a source route bridge frame is used to define a route through an internetwork between the end nodes D1 and D7.
Figure 9. Source Route Bridging
2.7.3 Source Route Transparent Bridging (SRT)

The IEEE 802.1 committee identified the need for source route bridges to interoperate with transparent bridges in the same internetwork. A source route transparent bridge (SRT) standard has been defined to achieve this goal. The principle behind SRT bridges is very simple. A SRT bridge inspects all received frames and looks for the presence of the routing information indicator (RII) and the routing information field (RIF). If these fields are present, the SRT bridge uses them and acts as a source route bridge. If not, the SRT bridge operates in transparent bridge mode and forwards frames based on their MAC sublayer destination address and its associated entry in the filtering database. The source route transparent bridge does not allow source route bridge devices to communicate with transparent bridge devices. A SRT bridge has the capability to understand both source route bridging and transparent bridging devices. However, a SRT bridge will never translate source route bridge frames into transparent bridge frames or vice versa.
22
Figure 10 shows how a source route transparent bridge forwards token-ring frames as token-ring frames and Ethernet frames as Ethernet frames.
Figure 10. Source Route Transparent Bridge
2.7.4 Source Route - Translational Bridge (SR-TB)

The source route - translational bridge (SR-TB) is not an ISO standard definition. However, more and more bridges are implementing the SR-TB because of the need to interconnect source route bridge domains with transparent bridge domains. The goal of the source route - translational bridge is to translate the source route bridge frame into a transparent bridge frame and vice versa. The SR-TB bridges have to change the MAC layer protocol from (or to) Ethernet protocol to (or from) token-ring protocol. Actually, regarding the ISO bridge definition, this translation does not belong to a bridge. But it is implemented in a lot of bridges in order to be able to interconnect source route bridge domains and transparent bridge domains regardless of the protocol of the upper layer.
23
Figure 11 shows how the SR-TB allows a SRB device with RII=1, to communicate with a STB device (RII=0).
Figure 11. Source Route - Translational Bridging
See Figure 12 for a summary of bridging techniques.
Figure 12. Summary of Bridging Techniques

SRB means token-ring to token-ring. STB means Ethernet to Ethernet. A SRT (Source Route Transparent) bridge means the same box can do each of the above independently of the other. It can be used to interconnect either two Ethernet LANs together or two token-ring LANs together.
24
SR-TB means token-ring frames are translated to Ethernet frames and vice versa. A SR-TB bridge allows you to connect an Ethernet LAN to a token-ring LAN.
2.7.5 Overview of Routing

While bridges switch at layer 2 of the OSI model, routers operate at layer 3 (the network layer). The network layer is protocol dependent which means that the router has to understand each of the protocols that it has to route. In order to perform this, the router must have a routing table for each protocol that tells it where to send a packet for a particular destination. Finally, a router can only route protocols which have an address at the network layer. Some protocols (for example, SNA, NetBIOS, DEC LAT) do not provide such a visible address and thus are not routable. The main strengths of routing include protocol prioritization, isolation of network segments and extended network management. Because routers have visibility of the protocols that they are routing, they also give us the ability to prioritize protocols against each other. Also, it is possible to define detailed filter schemes on each protocol to protect the network from unauthorized access. Routers also, generally, provide much greater management capabilities over conventional bridges. This can allow network mangers greater operational control over their network (see Chapter 17, Network Management in Router Networks on page 537). LAN broadcasts (for example, those issued by NetBIOS when searching for a resource) are not forwarded by routers. Therefore, a routed network provides some degree of isolation between network segments. On the negative side, routers are by their very nature more complex than bridges. Each router has to be configured with the details of each protocol that it is routing. This information must be updated should any of this information change. Routers themselves require management. Finally, routing is not a solution for all protocols. Some protocols cannot be routed.
25
2.8 Routable versus Nonroutable Protocols

Why are some protocols described as nonroutable ? What does this mean? More importantly, what actually makes a protocol routable? This section covers these questions with answers that are surprisingly simple. To illustrate the answers, we will look at some common protocols: IP, SNA (subarea SNA and APPN) and NetBIOS. What makes a protocol routable? Simply, it is the presence of a unique address at the network layer of the protocol (remember that routers switch at the network layer). Let us take a look at some of the common protocols to see which are routable and which are not.
2.8.1 TCP/IP
TCP/IP is a classic example of a routable protocol such as IPX and some others (see Table 7 on page 29). First, let us have a look at the structure of TCP/IP related to the 7 layer model.
Table 5. TCP/IP Relationship to OSI 7 Layer M o d e l
7 6 5 4 3 2 1
Application Presentation Session Transport Network Data Link Physical
FTP, TELNET, SMTP ...
TCP/UDP IP LLC/MAC
At the network layer of TCP/IP, IP provides a unique addressing structure based upon the IP address. Each IP address is basically split up into two parts: the network number and the host address . Because this addressing structure contains the concept of an IP network, routers can make routing decisions on that network to route traffic to the correct destination. To illustrate this point, let us look at the following example in Figure 13 on page 27:
26
Figure 13. IP Routing - Sample IP Network Configuration
If router A receives a packet for IP network 9.67.3.0, it knows, either by static or dynamic routing (See 3.1.3, Summary of OSPF versus RIP on page 34) that router C is on this network and all packets should be forwarded towards it.
2.8.2 NetBIOS
While TCP/IP is a classical example of a routable protocol (it has a network address at layer 3), NetBIOS is a good example of a protocol that is nonroutable. Again, to see this, let us look at the NetBIOS protocol stack in Table 6:
Table 6. NetBIOS Relationship to OSI 7 Layer M o d e l
7 6 5 4 3 2 1
Application Presentation Session Transport Network Data Link Physical Note that NetBIOS is a layer 4 (transport) protocol and, importantly, lacks a network layer and particularly a network layer address. Because NetBIOS does NetBIOS *None* LLC/MAC
27
not provide a network address, routers (which operate at layer 3) cannot route the NetBIOS protocol. As before, let us consider a sample network as follows:
Figure 14. NetBIOS Routing - Sample NetBIOS Network Showing Domains
Consider the routers in this example. If they receive a packet for a NetBIOS machine, how do they know where to send it? There is no valid address at layer 3 for them to route upon. All addresses in the NetBIOS world are held at layer 4 (transport layer). Note that the NetBIOS concept of a domain does not equate to a network, that is, the domain Joe can exist in multiple locations as in the previous example. If, for example, router A received a packet for a machine in domain Joe, how would it know where to send it? Each of the three routers has an interface in domain Joe.
2.8.3 Subarea SNA

A common statement that is made is that subarea SNA is not routable. This is a misconception. Front-end processors (37x5s) and the host VTAM have been routing subarea SNA ever since its original design. In fact, a 37x5 is an SNA router. The important point here is that the logic and addressing required to route subarea SNA is contained within the 37x5 and host VTAM and is not visible
28
outside them. Thus, router products cannot themselves route subarea SNA as they cannot see the network layer addresses.
2.8.4 APPN
A special example of the SNA protocol is APPN. APPN is routable via High Performance Routing (HPR). Unlike a conventional SNA data packet, an HPR data packet contains all the information needed to route the packet to the destination node.
2.8.5 Protocol Summary

The following table lists many of today s current protocols and states whether they are routable or not:
Table 7. Protocol Summary
Protocol TCP/IP IPX Subarea SNA APPN NetBIOS DECnet Vines AppleTalk XNS DEC LAT
Routable Yes Yes No Yes No Yes Yes Yes Yes No
Comments
Not routable by router products Routable via HPR
Use bridging or Cisco tunnel
Note: By routable in the above table we mean routable by a multiprotocol router such as a 2210 or 2216.
2.9 Summary
In this chapter we asked, why do we need support for different protocols? The answer to this question is that we are governed by the applications that we use. Certain applications have been written to use certain protocols. We then briefly examined four of the more common protocols in existence today: SNA (including APPN), TCP/IP, IPX and NetBIOS summarizing the key points of each. SNA remains important for its strong quality of service, TCP/IP for its interoperability, IPX for its large installed base of Novell NetWare and similarly NetBIOS because of the IBM LAN Server installations. We then moved on to examine bridging and routing, highlighting the key points of each and comparing the two techniques. Finally, we looked at what makes a protocol routable. We have seen that this is the presence of a unique address at the OSI network layer (layer 3). We then described which common protocols are routable and which are not.
29
30
Chapter 3. Router Technology

This chapter describes the common techniques and technologies used in router products. It will cover the following areas:

How routers work Data link switching (DLSw) Boundary Access Node (RFC 1490) SDLC support Router APPN support
We start with a discussion of how routers work and in particular we describe how routers route packets to the correct destination. After this, we then move on to describe some techniques used within routers to transport nonroutable data across router networks. Data link switching (DLSw) is a mechanism for transporting SNA or NetBIOS data across an IP network, Boundary Access Node is a mechanism for transporting SNA data across a frame relay network, and SDLC Relay is a method of encapsulating SDLC traffic in IP. We also look at the IBM router support of APPN.
3.1 How Do Routers Work?

More accurately, how do routers direct traffic so that it gets to the correct destination? Each router within the network maintains routing tables. These tables contain the rules that the router will use when it receives a packet that it has to forward. The format of these routing tables are generally very simple; usually they only contain three pieces of information as follows:

Destination Interface Next hop router
The destination is the address of the received packet. The interface specifies which of the physical interfaces in the router the packet should be forwarded out on and the next hop router specifies which router the packets should be directed to. Let us illustrate these points by means of an example that we have used once before.
31
Figure 15. IP Routing
Let us now look at the routing tables that would be required for all three routers so that they could route between themselves.
Table 8. Network Routing Table for Router A Destination 9.67.1.0 9.67.2.0 9.67.3.0 Interface LAN WANB WANB Next Hop *None* Router B Router B
Table 9. Network Routing Table for Router B Destination 9.67.1.0 9.67.2.0 9.67.3.0 Interface WANA LAN WANC Next Hop Router A *None* Router C
32
Table 10. Network Routing Table for Router C Destination 9.67.1.0 9.67.2.0 9.67.3.0 Interface WANB WANB LAN Next Hop Router B Router B *None*
Note: WANx means the WAN link to Router X. If router A receives a packet destined for network 9.67.2.0, it will forward it to router B over the WAN interface. Router B will then send this packet out over its LAN connection. If router A receives a packet for the 9.67.3.0 network, it will send it over the WAN to router B. Router B will then send it over its WAN connection to router C who will then deliver it onto the LAN. Each router needs a separate routing table for each protocol that it is required to route. Finally, there comes the question of route table maintenance. It is possible to manually define all of these route entries; this technique is known as static routing . In small networks this may be possible, but in large networks the overheads of maintaining tables becomes too great. With dynamic routing protocols , each router swaps routing information with its neighbors and each builds up a complete topology of the network. In IPX, this dynamic protocol is known as RIP. With IP, two protocols are used: OSPF (Open Shortest Path First) and RIP (Route Information Protocol). Please note that IPX RIP and IP RIP are different protocols.
3.1.1 IP RIP
IP RIP is very similar to IPX RIP in that it works by each router periodically exchanging routing tables with each other router in the network (for IP every 30 seconds). Thus each router builds up a complete picture of the structure of the network. RIP is very straightforward and simple to configure; however, it can be inflexible and at Version 1 does not understand IP subnetting (RIP Version 2 does support variable subnetting). The IBM 2216 and IBM 2210 both support RIP Version 1 and Version 2. Also, in large networks, the exchange of routing tables can cause large amounts of traffic to be transmitted across links every 60 seconds. IP RIP is hop-count based when it comes to calculating routes through the network. This means that IP RIP will choose a route based on the least number of hops from source to destination.
3.1.2 OSPF
OSPF is a more recent protocol than RIP and was designed to get around the limitations of RIP. The result is a complex protocol which provides much greater flexibility. Rather than being hop-count based like RIP, OSPF works by assigning a cost to each link within the network and picking the least cost route between destinations. This generally will result in a more optimum routing than RIP if the user-defined costs for each link are sensible. For example, consider the diagram in 15.2, Second Telecommunications Circuit on page 519 (Figure 491 on page 519). If the link between the two remote sites was a slow-speed link and should only be used in backup situations, OSPF could be tailored to support this by assigning this link a high cost. IP RIP would always route down this link as it is the least hop route.
33
Finally, OSPF has full support for IP subnetting.
3.1.3 Summary of OSPF versus RIP

Finally, let us close this discussion by summarizing the following advantages and disadvantages of RIP and OSPF: RIP Advantages
Simplicity
RIP Disadvantages

Route table broadcast every 30 seconds No IP subnetting support at Version 1 Inflexible - hop-count based
OSPF Advantages

No periodic broadcasting of the full routing table IP subnetting support More optimal routing and more flexibility
OSPF Disadvantages
Complexity
3.2 Data Link Switching (DLSw) Overview

The IBM 2216 and IBM 2210 Multiprotocol Routers both implement data link switching as a mechanism for transporting non-routable protocols over a router backbone.
3.2.1 What Is DLSw?

A way of routing SNA and NetBIOS over an IP router network An alternative to bridging for SNA and NetBIOS
Data link switching (DLSw) is an IBM-defined architecture that allows the transport of SNA and NetBIOS protocols across an IP-based router network. Both the IBM 2216 and IBM 2210 platforms support DLSw. The RFC for DLSw (RFC 1434) is an Internet Activities Board standard. Various other vendors have produced versions of DLSw based upon the published RFC. In particular, Wellfleet, Cisco and Proteon have produced their own implementations. In addition, Cisco also supports Remote Source Route Bridging which offers a similar, although incompatible, function to DLSw. DLSw is basically an encapsulation of SNA and NetBIOS inside TCP/IP. TCP is used to provide a reliable end-to-end delivery of the SNA and NetBIOS traffic across the router network. Because IP is used as the network layer protocol, DLSw does not supply the sophisticated Class of Service (COS) guarantees that conventional SNA networks do. As a result, it can be very difficult to provide consistent response times across an SNA over DLSw session. Within router networks, DLSw is an excellent alternative to bridging. Additionally, DLSw can also be used to support SDLC-attached devices. DLSw supports SDLC devices to LAN devices by converting the SDLC frames into LLC2
34
frames (LAN frames) and using the DLSw TCP sessions to transport them over the wide area. Thus, to the destination SNA device, the SDLC device appears as if it too is LAN-attached. DLSw SDLC also supports SDLC devices to SDLC devices. The end stations supported are SNA PU types 2.0, 2.1, 4 or 4/5.
3.2.2 DLSw Implementation

The following diagram shows a conceptual view of data link switching.
Figure 16. DLSw Overview: Overview of DLSw Showing IP Encapsulation
As mentioned previously, DLSw provides for the transport of SNA traffic across an IP network. To perform this, each router listens to SNA frames transmitted on the LAN. SNA frames are identified by the router by a special field contained within the frame called the Service Access Point (SAP). This SAP field contains a hexadecimal value that indicates which protocol the frame is carrying. SNA generally uses SAPs X 00 and X 04. In order to listen to SNA frames, the LAN adapter on each router must be configured to perform bridging (source route for token-ring and transparent for Ethernet) and to forward bridged frames to the DLSw function within that router. Once DLSw has received an SNA frame, it then checks the destination address in its DLSw routing table (note that DLSw routing tables are similar to IP routing tables - 3.1, How Do Routers Work? on page 31). If the destination has not yet been discovered, then the router asks each of its DLSw partners if they know where the destination address is. If one of the partners sends back a positive response, then the SNA frame is sent to that router and an entry is placed in the DLSw routing table so that all future packets to that destination follow the same path without the need to ask the partners each time.
35
The end devices do not know that the SNA traffic is flowing across an IP network. What they think they see is the router acting as a bridge and the device that they are talking to existing on a segment one hop away on the virtual ring. Thus, to device A, device D appears as if it is on segment AAA. Also, device A appears to device D as if it is on segment AAA. Please note, the bridging involved here is not real bridging. It is a technique used by DLSw to hide the fact that the SNA traffic is actually being transported across an IP network. We have mentioned earlier that the use of IP in the backbone to carry SNA data can cause problems with the consistency of response times, etc. However, we should also say that the use of IP can also provide advantages. Because IP is a connectionless protocol, it is capable of routing around physical link failures inside the backbone without any loss of sessions. As long as IP reroutes (using a protocol like RIP or OSPF) within the TCP timeout value (the default is 120 seconds), then SNA sessions will not be lost. Because the DLSw standard is open (RFC 1795), vendors can choose to implement their own value added features to DLSw and still be interoperable with other versions of DLSw that do not support these features. The features supported are exchanged when a TCP session is established and agreed upon between the two routers. Finally, we describe a feature of DLSw that ensures that the SNA sessions are not lost due to wide area network congestion. In a conventional SNA network (such as a bridged network) there is an LLC2 (layer 2) session between the end devices. Over wide area network connections, this LLC2 session can be lost if the responses are delayed due to congestion. DLSw alleviates this problem by terminating the LLC2 connection between the devices at the routers and locally acknowledging the LLC2 frames (spoofing). This means that LLC2 timeouts will not occur due to network congestion, and moreover, the LLC2 frames are not actually transmitted over the wide area.
36
Figure 17 illustrates how in DLSw the LLC2 frames are acknowledged by the router.
Figure 17. LLC2 Termination in DLSw
3.2.3 Problems with DLSw

DLSw provides an alternate means to transport SNA traffic across an IP network. However, it does have some drawbacks and problems. First, DLSw makes use of an underlying IP network. This means that the SNA data is running on top of a network protocol that does not provide sophisticated flow control or error control. Even though the end devices may be using SNA concepts such as Class of Service (COS), once inside the IP network these concepts can not be guaranteed. This means that providing consistent SNA response times may be very difficult over DLSw. Also, currently there is no recognition of SNA COS by the DLSw itself. This means that there is no prioritization by the router of interactive SNA traffic over batch. Secondly, each SNA frame being handled by DLSw has to be encapsulated into TCP/IP on entry to the IP network and decapsulated into SNA on its exit. While the delays in performing this operation are small, they can be noticeable on heavily loaded routers. An important consideration is that SNA over DLSw will not provide as good or as consistent response times as a pure SNA network based on 37x5, 3172, AS/400, etc.
37
3.2.4 DLSw versus Bridging

An often asked question is: When should I use bridging and when should I use data link switching ? As might be expected, the answer is not as simple as the question and will depend on many factors. First, DLSw was designed to address some of the problems with bridging over the wide area. For a purely local environment (no wide area connections), bridging is the better option. In fact, DLSw should not be used on local LAN connections.
Figure 18. Diagram Showing Where to Bridge and Where to DLSw
The primary function of DLSw is to maintain the integrity of SNA sessions across low speed WANs. It accomplishes this by providing congestion control and minimizing the amount of data that has to flow across the WAN. DLSw terminates the layer 2 connection between the end devices by masquerading (spoofing) the destination endstation. This ensures a local response to all layer 2 frames. This prevents WAN timeouts and also allows us to perform congestion control on heavily used wide area links. Additionally, DLSw also supports SDLC devices by providing polling at the edge routers and conversion of SDLC into LLC2 (again reducing overhead traffic on the WAN). Finally, DLSw also buffers frames at the TCP layer to minimize the number of frames being transmitted across the wide area.
38
In summary, let us look at the following advantages and disadvantages of DLSw with respect to bridging: DLSw Advantages
Session protection Elimination of LLC2 timeouts and session termination Efficient WAN utilization Elimination of LLC2 traffic across the WAN Reduction in broadcast traffic TCP buffering - blocking of multiple DLSw frames into one TCP frame Congestion and flow control Router to endstation (LLC2 busy - RNR) DLSw to DLSw flow control TCP flow control Dynamic routing within the IP backbone (OSPF or RIP) Reliable transport across the WAN by TCP IP network rerouting without session failure Prioritization of traffic over the wide area DLSw Disadvantages Lower throughput 700 - 800 frames per second aggregate throughput Processor Utilization DLSw frames are processed by the main processor on the routers; that is, they are not handled on the card. Processor utilization becomes the primary throughput limiting resource as traffic loads increase. Longer latency The data flow and the TCP buffering increase the latency through the router.
39
3.3 Boundary Access Node Function

The Boundary Access Node function is a standard (documented in RFC 1490) that allows direct encapsulation of protocols in frame relay (layer 2) packets. Support is now available in the IBM 2216 and IBM 2210 that allows the direct encapsulation of SNA data by RFC 1490 into frame relay packets for decapsulation by an SNA host such as a 37x5 or AS/400.
Figure 19. BAN Frame Relay Encapsulation
The IBM 2216 and IBM 2210 can also be configured to provide the local LLC2 termination to prevent wide area timeouts if the frame relay network becomes congested. BAN support can also be used to route IP data from the router (2210 or 2216) to the SNA host (37x5 or AS/400). BAN is, by its very nature, a more efficient technique than DLSw. Because DLSw uses TCP/IP to transmit SNA across the wide area, every DLSw packet that is sent has approximately 60 bytes of headers and trailers. With BAN, because we are using straight encapsulation in the frame relay packet (layer 2), the overhead is much less (on average about 16 bytes in total). This means that the BAN technique has a higher potential throughput than DLSw. Second, is the issue of scalability. With DLSw we require TCP connections to each of our remote partners. There is a finite limit on the number of those TCP
40
connections that we can maintain on both the 2216 and 2210. The 2216 has an upper limit of 100 TCP connections; the 2210 has a lower upper limit. With BAN, we are only limited to the number of DLCIs that we can configure. Both the 2210 and 2216 support over 200 DLCIs per router. To balance these two points, however, BAN support is only available on frame relay networks.
3.4 SDLC Support

The IBM 2210 and IBM 2216 support 2 types of SDLC support:

SDLC using DLSw (data link switching). SDLC relay.
First we will look at the support of SDLC traffic with DLSw. The types of end stations supported are:

PU PU PU PU
2.0 2.1 4 4/5 (a host or NCP performing the SNA boundary function)
The router can serve in either primary, secondary or negotiate SDLC link station role. In the primary role, the router can support multiple SDLC devices of differing PU types on the same physical multipoint SDLC line. In the secondary role the router can represent multiple SDLC secondary stations on a single physical SDLC interface. SDLC Relay is a technique that allows the direct encapsulation of SDLC traffic inside IP to connect two SDLC-attached devices together. SDLC Relay is also known as Serial Tunnelling .
41
Figure 20. SDLC Relay
The router simply encapsulates all SDLC frames in IP and forwards the packet to a specified IP destination. The destination router removes the IP headers and forwards the SDLC frame onto its SDLC link. All of the SDLC frames (including link level Receive Ready frames) will cross the IP network as SDLC Relay does not perform local acknowledgment like DLSw. This means that SDLC Relay may suffer session timeouts due to IP network congestion. The SDLC Relay implementation is not limited to a specific PU type.
3.4.1 Comparison between DLSw SDLC and SDLC Relay

With SDLC relay there is no SDLC link station operating in the router. Control frames (for example, RRs) flow across the IP network. With DLSw the router s SDLC support terminates the control frames. With SDLC relay both end stations must be SDLC. With DLSw protocol conversion can take place. DLSw supports SDLC, LLC or QLLC end stations. This can alter as DLSw support alters. With SDLC relay all types of SDLC functions are supported as the SDLC frame is passed transparently through SDLC relay. With DLSw certain SDLC configurations and functions are not supported (for example multiple transmission groups between NCPs).
42
In summary we suggest the following: Use DLSw SDLC support when:

You require protocol conversion of SDLC to LLC or QLLC You want to restrict control traffic (RR frames)
Use SDLC relay when;
You need SDLC-to-SDLC functions or configurations not supported by DLSw SDLC
3.5 IBM Router APPN Support

Both the IBM 2216 and IBM 2210 are capable of being APPN network nodes, with intermediate routing functions, and provide network services to both APPN and LEN nodes. The APPN network node can also attach to T2.0 nodes using the DLUR function. The APPN network node is able to establish CP-CP sessions with its adjacent APPN network nodes to exchange network topology and resource information. See SNA APPN Architecture Reference SC30-3422, Appendix A, base and option sets, for a detailed list of functions included in the Version 2 base.
3.5.1 Additional APPN Functions

The additional APPN functions supported are:

High performance routing (HPR) Dependent LU requester (DLUR) Branch extender Enterprise extender TN3270E server
High Performance Routing (HPR) HPR consists of enhancements to APPN s routing techniques. The main goals of HPR are to improve APPN s reliability by improving the data routing. A network may consist of a mixture of APPN and HPR nodes because HPR nodes fully interoperate with APPN nodes. Dependent LU Requester (DLUR) Dependent LU Requester in conjunction with a Dependent LU Server (DLUS) removes the requirement of direct attachment of a dependent LU to a VTAM or NCP. A dependent LU server at a VTAM network node will allow dependent LUs attached to other APPN end or network nodes (supporting dependent LU requester) to obtain sessions. Branch Extender Branch extender is a means of building large APPN networks without using excessive network nodes, and therefore reducing the amount of CP-CP sessions and topology data-base sizes. The network node configured as a branch extender appears as an end node to the upstream nodes and as a network node to its down-stream nodes.
43
Enterprise Extender Enterprise extender is a set of extensions to APPN High Performance Routing which allow SNA traffic to flow over an IP network. To the HPR network the IP network is a logical link, but to the IP network the SNA traffic is UDP datagrams. TN3270E Server The TN3270E server provides a TN3270 gateway function for TN3270 clients that are down-stream of an SNA host running a TN3270 application. The clients connect to the server via TCP/IP and this is mapped to a dependent SNA LU-LU session. The TN3270E server is responsible for the conversion from the TN3270 client data stream to SNA, and complies with RFCs 1646 and 1647. The APPN functions supported by Data Link Controls (DLCs) are:
Table 11. APPN Protocols by DLC PPP FR X.25 SDLC TR EN ATM 1483 N Y Y Y ATM TR LEC Y Y Y Y ATM EN LEC Y Y Y Y
ISR HPR DLUR TN3270E
Y Y N Y
Y Y Y Y
Y N Y Y
Y N Y Y
Y Y Y Y
Y Y Y Y
44
Chapter 4. IBM Router Products

This chapter looks at the IBM router products that exist in the market place today. It focuses on the function provided by each router and also describes how to position the products against each other. IBM is currently marketing two types of router, the IBM 2216 Nways Multiaccess Connector and the IBM 2210 Nways Multiprotocol Router.
4.1 The IBM 2216 Nways Multiaccess Connector

The IBM 2216 Nways Multiaccess Connector and Multiprotocol Access Service software is IBM s offering for regional router concentration, remote SNA concentration, high performance campus and data center access.
Figure 21. IBM 2216 M o d e l 400
The IBM 2216 is mainly intended for regional concentration in a large network connecting many remote branch offices to a central host site. The 2216 is capable of having up to eight networking adapters. The types of adapters and any limitations in the numbers or placement is shown later in this chapter. In addition to the adapters, the IBM 2216 has some unique features, such as:

Optional second power supply Adapter card hot plugging PCMCIA slots for supported modem cards
The IBM 2216 when using MAS 2.2 is capable of handling the following protocols and bridging methods:
45
Table 12. 2216 Protocol Matrix Interface vs. Protocol IP IPX SNA NetBIOS BAN DECnet Vines XNS ATalk SRB TB TRB Legend: BAN ATalk SRB TB TRB FR PPP DoD Boundary Access Node Apple Talk Source Route Bridging Transparent Bridging Translational Bridging Frame relay Point-to-Point Protocol Dial on Demand Serial & ISDN PPP Yes Yes Yes Yes No Yes Yes Yes Yes Yes Yes Yes FR Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes X.25 Yes Yes Yes Yes No No Yes No Yes Yes Yes Yes SDLC No No Yes No Yes Yes No No No No No No DoD Yes Yes Yes Yes No Yes Yes No Yes Yes Yes Yes Backup Yes Yes Yes Yes No Yes Yes No Yes Yes Yes Yes TR Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes N.A Yes E/net Yes Yes Yes Yes Yes Yes Yes Yes Yes N.A Yes Yes ATM Yes Yes Yes Yes No Yes Yes No Yes Yes Yes Yes FDDI Yes Yes Yes Yes No Yes Yes No Yes No Yes No
The IBM 2216 natively routes many of the more common protocols in use today. It also offers the industry standard Data Link Switching (DLSw) support for NetBIOS and SNA devices attached to token-ring and Ethernet LANs. In addition, it supports advanced SNA transport with APPN network node (NN), high performance routing (HPR) and dependant LU requester (DLUR). The IBM 2216 is only available as a model 400 and has 8 slots for communication adapters. It can be configured with a wide variety of communications adapters referred to as LICs (line interface couplers). The LICs available for the IBM 2216 are as follows:

2280 2281 2282 2283 2284 2286 2287 2288 2289 2290 2291 2292
2 port token-ring 2 port Ethernet 8 port EIA232/V24 Serial adapter 1 port ISDN PRI (T1/J1 interface) 1 port ATM 155 Mbps MMF 1 port FDDI 1 port ESCON channel 1 port 10/100 Mbps Ethernet 1 port HSSI 6 port V.35/V.36 8 port X.21 1 port ISDN PRI (E1 interface)
46
2293 - 1 port ATM 155 Mbps SMF 2294 - 1 port high performance ATM 155 Mbps MMF 2295 - 1 port high performance ATM 155 Mbps SMF
The IBM 2216 adapters can be positioned in any slot with the following exceptions:
Token-ring or Ethernet adapter in slots 3 or 7 require the adjacent slots (4 or 8) to be kept free. Token-ring or Ethernet adapter in slots 4 or 8 require the adjacent slots (3 or 7) to be kept free. Up to 2 ATM adapters can be installed Up to 4 ISDN adapters can be installed Up to 4 ESCON adapters can be installed
4.2 The IBM 2210 Nways Multiprotocol Router

The IBM 2210 is a joint venture between IBM, who provided the router hardware, and Proteon who provided most of the software. The operating system was then called MRNS and the last level was V1R3. Since then IBM has licensed the software and renamed it MRS (multiprotocol routing services).
Figure 22. IBM 2210 M o d e l 128
The IBM 2210 is designed to be a low end, branch office or remote router; it is not designed to be a backbone router. The IBM 2210, when using MRS V2R2, is capable of handling the following protocols and bridging methods:
Table 13 (Page 1 of 2). 2210 Protocol Matrix Interface vs. Protocol IP IPX SNA NetBIOS BAN DECnet Vines XNS ATalk SRB Serial & ISDN PPP Yes Yes Yes Yes No Yes Yes No Yes Yes FR Yes Yes Yes Yes Yes Yes Yes No Yes Yes X.25 Yes Yes Yes Yes No Yes Yes No Yes Yes SDLC No No Yes No Yes No No No No No DoD Yes Yes Yes Yes No Yes Yes No Yes Yes Backup Yes Yes Yes Yes No Yes Yes No Yes Yes TR Yes Yes Yes Yes Yes Yes Yes No Yes Yes E/net Yes Yes Yes Yes Yes Yes Yes No Yes Yes ATM Yes Yes Yes Yes No Yes Yes No Yes N.A
47
Table 13 (Page 2 of 2). 2210 Protocol Matrix Interface vs. Protocol TB TRB Legend: BAN ATalk SRB TB TRB FR PPP DoD Boundary Access Node Apple Talk Source Route Bridging Transparent Bridging Translational Bridging Frame relay Point-to-Point Protocol Dial on Demand Serial & ISDN PPP Yes Yes FR Yes Yes X.25 Yes Yes SDLC No No DoD Yes Yes Backup Yes Yes TR N.A Yes E/net Yes Yes ATM Yes Yes
The IBM 2210 supports the same protocols as the IBM 2216. The 2210 comes in a small number of fixed configurations as shown in the following list:

Model Model Model Model Model Model Model Model Model Model Model Model
1S4 - 1 port Ethernet, 1 port serial, 1 ISDN BRI 1S8 - 1 port Ethernet, 1 port serial, 1 ISDN BRI 1U4 - 1 port Ethernet, 1 port serial, 1 ISDN BRI 1U8 - 1 port Ethernet, 1 port serial, 1 ISDN BRI 12T - 1 port token-ring, 2 port serial 12E - 1 port Ethernet, 2 port serial 127 - 1 port token-ring, 2 port serial, 1 ISDN BRI 128 - 1 port Ethernet, 2 port serial, 1 ISDN BRI 14T - 1 port token-ring, 4 port serial 24T - 2 port token-ring, 4 port serial 24E - 2 port Ethernet, 4 port serial 24M - 1 port token-ring, 1 port Ethernet, 4 port serial
The 14x and 24x models have an extra slot, this slot can have one of the following adapters:

ISDN BRI-S/T ISDN Quad BRI-U ISDN PRI-T1/J1 ISDN Quad BRI-S/T ISDN PRI-E1 120-Ohm 4 port WAN connector 8 port WAN connector 25 Mbps ATM
Available from IBM is a program called 2210STOR which assists in determining the amount of 2210 memory required. The program is held on the IBM internal marketing tools database. All 2210 models, except the 1SX and 1UX models, are capable of having field upgradeable extra memory installed.
48
4.3 Choosing between the IBM 2216 and the IBM 2210
The 2216 and 2210 support the same protocols, the main reason for choosing between them is the number and variety of network adapters supported. For example, the 2216 is capable of supporting a 2 port LAN adapter and up to 7x 8 port V.35 LICs. This makes the 2216 capable of supporting 56 remote sites and hence able to act as a concentrator concentrating remote sites into a central host site. The 2210, with its versatility in different models and low cost, makes it the best choice for remote sites.
4.4 OEM Router Products

A wide variety of OEM products exist within the marketplace which we will not detail here. Router products from OEM suppliers do exist and can perform all of the functions listed in the previous tables.
4.5 Summary
IBM has two offerings in the router marketplace today. Starting at the low-end we have the IBM 2210 which is designed to be a branch office or remote router. It offers small to medium port density and is capable of routing many protocols natively. It supports SNA natively with APPN or over DLSw and ISDN. Secondly, we have the IBM 2216 Model 400, which along with IBM s open standards-based Multiprotocol Access Services software and an extensive and versatile range of adapters, provides a solution for medium to large router configurations. This can meet a variety of customer needs, one of which is to provide regional concentration of remote sites into a multiprotocol host site.
49
50
Chapter 5. AS/400 Networking Capabilities

The aim of this chapter is to provide information for the networking and router specialist not familiar with the AS/400. We concentrate on the AS/400 s capabilities in terms of communications and networking. It is not a detailed presentation so for greater depth on any particular subject, the reader should refer to the AS/400 communications manuals and appropriate redbooks.
5.1 AS/400 Networking Support

The AS/400, although traditionally a node found in APPN networks and a T2.1 node in SNA subarea networks, also supports TCP/IP, IPX/SPX and OSI networking protocols. The AS/400 is increasingly found in mixed IBM and non-IBM network environments. SNA, TCP/IP and IPX/SPX are part of the base support provided by OS/400. OSI is a separately licensed program product. NetBIOS is also supported as part of the LAN Server/400 licensed program product for the old FSIOP (File Server Input/Output Processor) or via the OS/2 Warp Server for OS/400 (5769-XZ1) or Windows NT Server on the IPCS (Integrated PC Server). The link protocol support is also provided by the base OS/400 code. We look at an overview of the communications support, hardware and software, provided on the AS/400e in the following tables. The number of lines and adapters supported depends on the model of the AS/400, which goes from the low end Model 600 (supporting up to 188 twinax attached devices) to the high end Model 650 (supporting up to 7000 twinax devices), plus the server models, and the AS/400e entry server models.
51
5.1.1 AS/400 Communications Hardware

The Advanced Systems and Advanced Servers support the following communications controllers and adapters.
MFIOP Multi function I/O Processor STANDARD
SLCC Six Line Comms Control or LAN/WAN/ WS IOP max of 3 Adapters 1Line or 2Line
High Speed WAN Adapter
Integr FAX Adapter SPD bus only
Integrated PC Server Wireless LAN FDDI/SDDI Ethernet 10/100Mbps or 16/4 Mbps TRLAN Adapter
* Disk * Tape * Dis kette up to 250 lines supported, * WSC depending on model * LAN
ECS or Client Access Console
up to 32 depending on model
up to 8 depending on model and adapters
First communication line is standard, can be used for: ECS (Electronic Customer Support) or for Client Access Console
Figure 23. Adapters Supported o n the AS/400
The MFIOP (Multi-Function I/O Processor) is a standard feature on the AS/400. It can be used to support either disk, tape, diskette, LAN or workstation controller attachments. It also supports two V.24 communications lines. As an alternative, an optional Client Access Console cable (feature 0362) can be used on one of these ports. Ethernet (10 or 100 Mbps) or 4/16 Mbps Token-ring are also supported as native AS/400 adapters or on the IPCS (Integrated PC Server). The PCI LAN/WAN/Workstation IOP is an optional feature for the systems with a PCI bus, like the Models 600 or 620, and can be used for attaching LAN, WAN and workstation IOAs (Input Output Adapters) in different combinations. Up to
52
six WAN attachments are supported, these can be V24, V.35, V.36 or X.21 in different combinations. The SLCC (Six Line Communications Controller) is an optional feature for the systems with SPD bus, like the 620 and up, and can support up to 6 communication lines via three adapter slots. These adapters can be a mixture of one or two line V.24 adapters, one or two line X.21 adapters, one line V.35 adapters or ISDN Basic Rate Interface adapters.
The IPCS (Integrated PC Server), previously named File Server Input Output Processor (FSIOP), is an optional feature which connects to the AS/400 to provide high performance file and application server capabilities to PCs. The IPCS can run Novell NetWare 4.10, IBM Warp Server for AS/400 (5769-XZ1), Lotus Notes, Windows NT or the IBM Firewall for AS/400 (5769-FW1). Integration Services for Integrated PC Server (5769-SS1 #2644) is a feature of OS/400 that provides the OS/2 WARP operating system for the IPCS/FSIOP. This feature allows the IPCS/FSIOP to be used as a token-ring or Ethernet adapter. OS/400 Integration for Novell NetWare (5755-AS5 #2645) and Novell NetWare 4.1 can be used with 5755-AS5 #2644 to provide Novell NetWare support on the AS/400. The licensed program WARP Server for AS/400 (5769-XZ1) provides IBM LAN Server support for the IPCS/FSIOP.
53
5.1.2 Adapters and Interfaces

Communication Controllers are integrated into the AS/400 System Unit. Comms Adpt Link Protocols Protocols running Ctrl Intf Frame concurrently ASYNC BSC SDLC X.25 Relay MFIOP V.24 19.2 19.2 19.2 19.2 SDLC, ASYNC, BSC, X.21 64 19.2 X.25 and X.21 SHM V.35 64 64 64 concurrently SLCC V.24 19.2 19.2 19.2 19.2 ASYNC, BSC, SDLC, X.21 64 64 X.25 and X.21 SHM V.35 64 640 64 concurrently ISDN two 64 Kbps links (2B+D) IDLC, X.25 High- V.35 2 M 2 M SDLC and Speed V.36 2 M 2 M frame relay WAN X.21 2 M 2 M not concurrently TRLAN Protocol is IEEE 802.2/.5 SNA, TCP/IP, at 4 or 16 Mbps IPX CSMA/ Protocol is IEEE 802.2/.3 SNA, TCP/IP, CD and Ethernet V2, at 10/100 Mbps IPX SDDI/ At 100 Mbps SNA, TCP/IP FDDI WLAN Spread Spectrum radio, operating SNA, TCP/IP in the 2.4 to 2.4835 GHz band IPCS IEEE 802.2/.3 and Ethernet V2 SNA, TCP/IP, IPX, or Token-Ring 802.2/.5 NetBIOS FAX Group 3 fax
Figure 24. Link Protocols Supported o n AS/400 Adapters
54
5.1.3 Network Architecture Support on Link Protocols

SNA TCP/IP OSI SDLC X ASYNC X SLIP X PPP BSC X25 X X X IDLC (ISDN) X FRAME RELAY X X SDDI/FDDI X X TOKEN-RING X X ETHERNET X X WIRELESS X X
Figure 25. Network Protocols versus Link Protocols
5.2 5250 Device Support

The AS/400 workstation data stream is 5250. The AS/400 supports locally and remotely attached non-intelligent 5250 devices and also locally and remotely attached PCs running 5250 emulation, such as provided by the Client Access/400 PC product.
5.2.1 Remote 5X94 Controllers

Remote controllers are supported for the remote attachment of workstations and printers. This includes the 5394 remote workstation controller and the 5494 remote workstation controller. The 5394 provides a WAN (SDLC or X.25) link to the AS/400 and supports twinax-attached 5250 devices. The 5494 supports either a WAN (SDLC, X.25 or frame relay) or LAN link to the AS/400. The single 5494 LAN adapter (token-ring or Ethernet) can either be used for the AS/400 connection or for LAN-attached 5250 devices. 5250 devices can also be twinax-attached to the 5494. The 5494 is an APPN LEN (low entry network) node.
5.3 AS/400 Communications Applications

The AS/400 provides applications for communicating in an APPN network, for communicating to a S/390 SNA host, for communicating in a TCP/IP network and an OSI network. We will describe some of these applications briefly in this section.
55
5.3.1 APPC Applications

The AS/400 is primarily an APPC host. APPC is the communications method of using the SNA LU Session Type 6.2 protocol. APPC stands for Advanced Program to Program Communications. APPN (Advanced Peer-to-Peer Networking) which the AS/400 also supports, allows data communications to route data between two or more APPC hosts in a network, that are not directly attached. The following are examples of APPC applications provided in the base AS/400 operating system (OS/400): Display Station Pass Through (5250 Passthrough), SNA Distribution Services (SNADS), Distributed Data Management (DDM) and Client Access/400. 5250 Passthrough is a communications function that allows a user to sign on to one system (AS/400 or S/36) from another system and use the remote system s programs and data interactively. SNADS (SNA Distribution Services) is a store and forward application that sends, receives and routes electronic mail, documents and files in APPN and SNA subarea networks. DRDA (Distributed Relational Database Access) is an LU6.2 application which provides a set of advanced SQL protocols to provide access to distributed relational databases. DRDA can be used to issue remote units of work to access data on a remote database in the following environments - AS/400 DB2/400, OS/2 DB2, DB2 (MVS) and SQL/DS (VM). DDM (Distributed Data Management) is a function which allows an application program or user on one system, to use data files stored on a remote system (that also supports DDM). To the user it appears as if the data is local. Client Access/400 provides a method of connecting personal computers to the AS/400 system. The Client Access/400 server code sits on the AS/400 and provides Database Server, File Server, Print Server and Electronic Mail Server support to the PCs. Client Access/400 provides two types of client support: Original Clients and Windows Family Clients. Original Clients are 16-bit clients for DOS with extended memory and the OS/2 32-bit version. The Windows Family Clients provide integration into the 16-bit Windows 3.x and the 32-bit Windows 95/NT enviroments.
5.3.2 AS/400 to S/390 Applications

The following examples are of applications which allow the AS/400 to communicate with S/390 mainframe hosts: SNA 3270 emulation, SNA Primary LU Support (SPLS), VM/MVS Bridge, and RJE (Remote Job Entry). SNA 3270 emulation allows the AS/400 user to remotely logon to a host system. The AS/400 appears as a PU Type 2 Control Unit to the host. 3270 display emulation converts the 3270 data stream, intended for a 3278 device, into a 5250 data stream which can be recognized by a display station attached to the AS/400. 3270 printer emulation converts 3270 data stream, intended for a 328x printer, into data stream that can be recognized by an AS/400-attached printer. 3270 emulation is part of OS/400. SPLS allows 3270 displays and printers, attached to a S/390 host, to communicate with the AS/400 as if they are 5250 devices directly attached to the AS/400. SPLS support is part of OS/400.
56
The VM/MVS bridge is a function provided by the AS/400 licensed program product Communications Utilities which provides distribution services between a SNADS network on the AS/400 and VM/RSCS, and between SNADS and MVS/JES. The AS/400 emulates an NJE node. This allows the AS/400 to send and receive electronic mail, documents, print output and files to and from the host. RJE is also a function provided by the AS/400 licensed program product Communications Utilities. RJE allows the AS/400 to submit jobs/data that require processing, to a host, utilizing the processing power of the host, while maintaining the application and data locally. It does not provide a signon panel to the host and requires host/JCL knowledge.
5.3.3 TCP/IP Support

The AS/400 has native TCP/IP support. This support allows the AS/400 to communicate with a great variety of non-IBM systems which support TCP/IP rather than APPC. OS/400 V4R2 TCP/IP support is fully compliant with RFC1122 and RFC1123. The TCP/IP applications that the AS/400 supports include TELNET, FTP, TFTP, BOOTP, DHCP, LPD/LPR, DNS, REXEC, electronic mail via SMTP or POP server, Internet Connection Server via HTTP, network management via SNMP and RIP support via ROUTED. TCP/IP support has been part of OS/400 from V3R1. The LAN and WAN protocols are supported in the base OS/400 code. The program product TCP/IP Connectivity Utilities, which is shipped free, provides the applications. The following is a brief overview of the TCP/IP applications supported: TELNET - The AS/400 provides both client and server support to allow AS/400 users to login remotely to TELNET hosts and to allow remote users on TELNET clients to login to the AS/400. FTP (File Transfer Protocol) - The AS/400 provides both client and server support for FTP. This allows files to be sent and received between the AS/400 and other FTP systems. TFTP (Trivial File Transfer Protocol) - The AS/400 provides server support for TFTP. TFTP is a simple protocol that provides basic file transfer function with no user authentication. BOOTP (Bootstrap Protocol) - The AS/400 provides server support for BOOTP. BOOTP provides a dynamic method for associating workstations with IP addresses and IPL (initial program load) sources. BOOTP and TFTP provide support, for example, for the IBM Network Station. DHCP (Dynamic Host Configuration Protocol) - The AS/400 provides server support for DHCP. DHCP provides hosts on a TCP/IP network with configuration information. LPD/LPR (Line Print Requestor/Line Print Daemon) - The AS/400 provides LPR support to allow the AS/400 client to send spool files to a remote LPD server system. It also provides LPD support to allow it to receive print output from remote LPR systems. SMTP (Simple Mail Transport Protocol) - The AS/400 allows users on the AS/400 to send and receive electronic mail and documents over a TCP/IP network via
57
SMTP. The user interface to this protocol is through the Office Vision/400 licensed program product on the AS/400. POP (Post Office Protocol) - The AS/400 allows users, this includes clients running any MAPI (Messaging Application Programming Interface) like Windows, OS/2, AIX or Macintosh, to exchange mail (including MIME mail) between OfficeVision/400 and POP clients by using the Anymail/400 mail server framework. This support is part of OS/400 V3R2 and up. Internet Connection Server - This is the AS/400 implementation of HTTP (Hypertext Transfer Protocol) which allows internal clients (Intranet) or external clients (via the Internet) to view HTML (Hypertext Markup Language) documents or use any WEB-enabled application stored on the AS/400. There is also an Internet Connection Secure Server licence program (5769-NC1 or 5769-NCE) which provides support for SHTTP (Secure Hypertext Transfer Protocol). Routed (Route Daemon) - The AS/400 provides support for the Routing Information Protocol (RIP). RIP is the most widely used dynamic routing protocol in use today. Dynamic routing protocols allow, for example, the automatic switching to backup routes. DNS (Domain Name System) - The AS/400 DNS support can be used to map hostnames to IP addresses on the TCP/IP network. There are two DNSs available on the AS/400. One is an DNS server that runs native on the AS/400 and is packaged as part of OS/400 option 31, 5769-SS1 Domain Name System. The other DNS server is part of the IBM Firewall for AS/400 licensed program 5769-FW1 that can be run on the IPCS (Integrated PC Server). These two DNS servers prevent the outside world from seeing the structure of your network. REXEC (Remote Execution) - The AS/400 provides both client and server support for REXEC. REXEC allows a client user to submit system commands to a remote server system. SNMP (Simple Network Management Protocol) - The AS/400 functions as an SNMP agent in an SNMP-managed network. It provides, for example, MIB II and APPN MIB databases for interrogation by an SNMP manager.
5.3.4 OSI Support

The AS/400 supports the networking protocol OSI. OSI was developed as a standard by the International Organization for Standardization (ISO). This allows the AS/400 to interoperate with a variety of non-IBM systems, which support this open networking architecture. The AS/400 supports the following OSI standards: X.400, FTAM, X.500 and Network Management. The AS/400 implements OSI with three licensed programs: OSI Communications Subsystem, OSI Message Services/400 and OSI File Services/400. OSI Communications Subsystem provides configuration functions, network management support and directory services (X.500). It also provides the lower layer support to allow the AS/400 to establish a connection via X.25 to another OSI host. OSI Message Services/400 provides X.400 services for the sending and receiving of electronic mail and documents. It implements the 1984 level of X.400. The user interface to X.400 is via the licensed program product Office Vision/400 for
58
electronic mail, and via the SNADS commands SNDNETF, SNDNETMSG and SNDNETSPLF to allow users to transfer files, messages and spool files. OSI File Services/400 provides FTAM (File Transfer Access and Management) services. It allows file transfer and file management. A menu-driven user interface is supplied allowing you to interactively transfer and manage files.
5.3.5 NetBIOS Support

NetBIOS is supported on the AS/400 by the LAN Server/400 product. LAN Server/400 software supports the file server I/O processor (FSIOP) providing high performance file serving to a PC running LAN Requester. OS/2 Warp Server for OS/400 (5769-XZ1) or Windows NT Server also support the Integrated PC Server (IPCS).
5.3.6 IPX Support

Native IPX support is now available on the AS/400. This allows the AS/400 to transparently route IPX. IPX packets can be transported from one IPX network into another, either LAN-to-LAN or LAN-to-WAN, via the AS/400. The AS/400 implements RIP and NLSP for routing in an IPX network. Applications can be written to IPX sockets. IPX is also added to AnyNet/400, which will allow AS/400 users to transport native APPC application data over an IPX backbone. NetWare application server support is available via the FSIOP (File Server IOP); that is, Novell NetWare 4.1 can be installed on the IPCS/FSIOP.
5.4 AS/400 Communications Configuration

Before the AS/400 can communicate with a remote system or device, a communications configuration must be built. In many cases part of this configuration will be auto-configured when the system or device first contacts the AS/400. An auto-created configuration description is denoted by CREATED BY AUTO-CONFIGURATION or AUTOMATICALLY CREATED BY QLUS in the text field of the description. Configuration objects can either be created via a menu option or via a command. The main communications configuration menu can be reached by either taking option 6 from the main menu followed by option 4 or by entering the command GO CFGCMN. The following menu will be presented:
59
CFGCMN
Configure Communications and Remote Hardware System: Select one of the following: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Work Work Work Work Work Work Work Work Work Work Work Work Work with with with with with with with with with with with with with lines communications controllers work station controllers communications devices printers display stations modes classes-of-service configuration lists network interfaces connection lists network servers NetBIOS descriptions
RALYAS4B
More... Selection or command ===> F3=Exit F4=Prompt F16=AS/400 main menu F9=Retrieve F12=Cancel F13=Information Assistant
Figure 26. AS/400 Communications Configuration M e n u
An example of a communications configuration command is CRTLINSDLC (Create SDLC Line). If F4 is pressed after typing in the command, the system will prompt for input as shown in the following:
Create Line Desc (SDLC) (CRTLINSDLC) Type choices, press Enter. Line description . . Resource names . . . + for Online at IPL . . . Data link role . . . Physical interface . Connection type . . . . . . . . . . . . . . more values . . . . . . . . . . . . . . . . . . . . . . . . Name Name *YES *NEG *RS232V24 *NONSWTPP *YES, *NO *NEG, *PRI, *SEC *RS232V24, *V35, *X21, *NONSWTPP, *SWTPP, *MP, *SHM
F3=Exit F4=Prompt F5=Refresh F13=How to use this display
F10=Additional parameters F24=More keys
Bottom F12=Cancel
Figure 27. AS/400 Communications Configuration Command Example
When the information requested in the panel above has been entered, further information is prompted for. The commonly used communications configuration objects are as follows:
60
Network Interface Line Controller Device APPN local location list APPN remote location list Mode
In addition to the above, the system network attributes include system-wide communications configuration information, such as the system network ID. A network interface describes an interface to a network. Currently, network interfaces are used with two types of networks: ISDN and frame relay. Where the network is ISDN or frame relay, the network interface is the first configuration object created. The network interface is used to define, for example, the network type and the interface type. The network interface also defines the communications port (resource name) to be used. A line description describes the local system (the AS/400) and the communication type. It also describes the physical interface (V.24, etc.) between the local system and the network, whether the line is switched or nonswitched and the network address (for example, X.25 NUA) of the local system. With the exception of ISDN and frame relay, the line description is the first configuration object created. Where there is no network interface, the line description also defines the AS/400 communications port (resource name) to be used. A controller description describes the characteristics of the remote system. It may describe a physical device (for example, a 3174/5494 remote workstation controller), or it may describe a logical connection to a remote system (for example, an APPC/APPN connection). If the remote system or device is reached via a switched connection, the controller description will also include the network address/telephone number/MAC address of the remote system. In the case of an APPN connection, the controller description will contain the network ID and CP name of the remote system/device. The controller description is normally created after the line description. In some cases (for example, a LAN connection) the controller descriptions can be auto-created provided that the parameter has been set in the associated line description to permit this. In SNA terminology, a controller description can be thought of as defining a PU. A device description describes the characteristics of a physical or logical device. For example, in the case of a 3174, the device description could describe a display attached to the 3174, or in the case of an APPC connection, the device description would describe a communications session. The device description is normally created after the controller description. In the case of an APPN connection, the device descriptions would normally be left to auto-create. In SNA terminology, a device description can be thought of as defining an LU. The APPN local location list is used to define the aliases for the local system. The default local location name (LU name) for the system is defined in the network attributes. If additional names are required, these are defined in the APPN local location list. The system will give a positive reply for APPN search requests received when the name is either: the CP name of the system, the default local location name of the system or the name is in the APPN local location list.
61
The APPN remote location list is used to define remote location names (LU names). In most cases a remote location list entry is not required. Some examples of where an entry is required are:
Where the remote location (LU) cannot be located via an APPN search request. The most common example of this is where the location (LU) resides within a non-APPN VTAM host. Where the requirement is for passwords to be used when establishing a connection to a remote system. Where the remote location is via APPC over TCP/IP (AnyNet).
Mode descriptions describe session characteristics. Mode descriptions for the common modes (BLANK, #INTER, #BATCH, etc.) are system supplied. Before a session can be established using a mode other than one that is system supplied, a mode description must be created. Each mode description has an associated Class of Service (COS). The system network attributes describe system-wide values. These system-wide values include communications definitions. The network attributes are accessed either by taking option 6 from the main menu followed by option 5 then option 1 or via the command DSPNETA. Some examples of the communications definitions defined in the network attributes are: System Network ID, System CP Name, Default Local Location Name, APPN Node Type and the Default Mode used when establishing a session. To summarize, the AS/400 communications objects are related to each other as shown in the following:
Network Interface (Frame relay and ISDN only) Line Description Controller Description Device Description Mode Description
Each of the above communications objects has a name associated with it. The objects are linked to each other via these names. Once created, the communications configuration objects can be activated (Vary on) or de-activated (Vary off) again via either the system menus or a command. The object type and object name are used when accessing a specific object. For example, to show the current status of a line description and allow the status to be changed, you can either take option 6 from the main menu followed by option 1 then option 1 or enter the command WRKCFGSTS *LIN. By default, this menu option and command will show all line descriptions. As an example, if you wanted to determine the status of the line description L31TR, the command WRKCFGSTS *LIN L31TR would result in the following:
62
Work with Configuration Status 07/07/95 Position to . . . . . Starting characters
RALYAS4B 13:33:56
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 9=Display mode status ... Opt Description L31TR WTR05130 WTR05130 QPCSUPP L31TRNET L31TRTCP00 Status ACTIVE ACTIVE ACTIVE ACTIVE/TARGET VARIED OFF VARIED OFF
8=Work with description
-------------Job--------------
WTR05130
MICK
003376
Bottom Parameters or command ===> F3=Exit F4=Prompt F12=Cancel
F23=More options
F24=More keys
Figure 28. AS/400 Work with Configuration Status Command
Besides showing the status, this panel also allows the status to be changed. For example, activated via option 1 (Vary on). In addition to showing the status of the line description (L31TR), the command also shows the status of communications objects associated with the line description. In this example it shows an APPC controller (WTR05130), a device description (WTR05130) and the mode being used for the active session (QPCSUPP). A TCP/IP interface is also associated with this token-ring line description. The system created configuration objects for this are also shown (L31TRNET and L31TRTCP00). For further information on AS/400 communications configuration, see AS/400 Communications Configuration , SC41-5401. The AS/400 TCP/IP configuration can also be carried out via either the system menus or commands. The main TCP/IP configuration menu is accessed via either option 6 followed by option 4 and then option 20 from the main menu or by entering the command CFGTCP. The following panel is presented:
63
CFGTCP Select one of the following: 1. 2. 3. 4. 5. 10. 11. 12. 13.
Configure TCP/IP System: RALYAS4B
Work with TCP/IP interfaces Work with TCP/IP routes Change TCP/IP attributes Work with TCP/IP port restrictions Work with TCP/IP remote system information Work with TCP/IP host table entries Merge TCP/IP host table Change local domain and host names Change remote name server
20. Configure TCP/IP applications 21. Configure related tables
Selection or command ===> F3=Exit F4=Prompt F9=Retrieve F12=Cancel
Figure 29. AS/400 TCP/IP Configuration M e n u
If a command interface is preferred, the ADDTCPRTE command, for example, will create a route definition. As before, if F4 is pressed after typing in the command, the system will prompt for input. For further information on AS/400 TCP/IP configuration, see AS/400 TCP/IP Configuration and Reference , SC41-5420-01.
64
Part 2. Part 2 - Router Scenarios

Part 2 contains various tested and documented AS/400 networking scenarios using IBM 2210 and IBM 2216 multiprotocol routers. The aim is to configure a variety of multiprotocol router networks which include AS/400 systems, and to review any special requirements to allow communication with an AS/400 across the router backbone. Each chapter has the following layout:

An overview showing the entire network. A list of the hardware and software components involved. Sections that review the network based on a specific protocol. For example, we look at the layout of the TCP/IP network which is sitting within the multiprotocol network. In each of the above sections we include the configuration definitions of the AS/400 and any device communicating with it.
Finally, a section which documents the complete router definitions used to support the complete multiprotocol network.
In each chapter we include a variety of components apart from the routers and AS/400 systems (for example, Client Acces/400, IP client, NT workstation). The protocols included are SNA/APPN, NetBIOS, TCP/IP and IPX. The scenarios we look at are as follows:

IBM 5394 and SDLC Relay IBM 5494 Connectivity Using IBM 2210 APPN IBM 2210 Frame Relay Connectivity to an AS/400 Multiprotocol Connectivity using Two Routers Multiprotocol Connectivity with Backup Multiprotocol Central Site Connectivity APPN/HPR Encapsulation in TCP/IP (Enterprise Extender) APPN Network Extension (Branch Extender)
Before looking at the above scenarios, we look at the tools available for IBM 2210 and IBM 2216 router configuration.
65
66
Chapter 6. Router Configuration Tools

This chapter describes the configuration tools available for configuring IBM 2210 and IBM 2216 routers. There are two tools:

The Graphical Configuration Program The Command Line Interface
6.1.1 Graphical Configuration Program

The IBM 2210/2216 have a graphical configuration program which is capable of running on the following platforms:

IBM AIX IBM Operating System/2 Microsoft Windows
The Configuration Programs allow you to create configurations for the IBM 2210/2216 routers using a point and click interface. Some of the features of the configuration programs are:
The ability to retrieve an existing configuration from a device to either update or use as a template for another device. The ability to use any configuration in the database as a template for another device. The ability to configure the protocols in any order unless there are inter-protocol dependencies. The ability to group configurations together in configuration databases that reflect your network topology. The ability to upgrade configurations from a configuration database created with previous versions of the configuration program to the current format. The ability to add comments to the configuration for additional documentation. The ability to verify the completeness of a configuration before loading that configuration to a router. Guided configuration that describes procedures to configure protocols. Context-sensitive helps for panels and parameters. The ability to save configurations as backups or have multiple versions for the same router. A command line facility that can automate many tasks including reading, writing, sending, and retrieving configurations. The ability to create, edit, and read ASCII-formatted configuration files.
67
The IBM configuration tools for the IBM 2210/2216 and the IBM MSS are identical in usage. They all use a Navigation Window and a Configuration Window to guide you through the various configuration options and parameters. The level of configuration program we were using (V2R2), invoked a tutorial in the Configuration Window when the configuration tool was first started. This is to assist new or inexperienced users to become familiar with the configuration program.
Figure 30. 2216 Configuration Program Startup
Once the configuration has been created it can be saved to a database for backup. These files may then be re-loaded into a configuration program for update, migration to a new level or as a template to create a new router configuration. As neither the IBM 2210 nor IBM 2216 have a diskette drive to read the configuration file there are three main ways to send the configuration file to the router. 1. File transfer via the service port of the router. 2. TFTP to the router. 3. Use the Communications option in the configuration program to send the configuration to the router.
68
For option 1 Create the router configuration file. - For an IBM 2210 use Zmodem to send the configuration via the service port. - For an IBM 2216 use Xmodem to send the configuration via the service port. For option 2 - Create the router configuration file. - Check that the platform being used to TFTP the file to the router is capable of being a TFTP server (not all IP stacks support this function). - That the router has an IP address configured. - That the router is contactable via IP (test using IP ping). For option 3 - Create the router configuration file. - Check that the router has an IP address configured. - That the router is contactable via IP (test using IP ping). - That the router has SNMP configured with the correct community name and enabled for read write.
69
1. Before creating the router configuration it is always advisable to save the configuration.

To do a save, first select configure from the navigation window. Then select Save configuration as... You will then be prompted to enter a name for the configuration.
2. To create a configuration file select:

Configure from the navigation window. Create router configuration.. You will then be prompted to enter the path and name for the file.
Figure 31. 2216 Configuration Program
For a more detailed explanation of the capabilities of the configuration programs please refer to Configuration Program User s Guide for Nways Multiprotocol Access Services , GC30-3830.
70
6.1.2 Command Line Interface

Although not strictly a configuration tool, but certainly a very popular method of configuring IBM 2210 and IBM 2216 routers, is the command line interface. This can be accessed from an ASCII console connected to the service port of the router, or by a telnet connection to the router. It is important to note that the IBM 2210 and IBM 2216 use different ASCII terminal emulation, file transfer modes and different default baud rates. 1. For an IBM 2210 use:

Baud rate 9600 VT100 terminal emulation Zmodem for file transfer
2. For an IBM 2216 use:

Baud rate 19200 VT220 terminal emulation Xmodem for file transfer
To navigate the command line interface to configure the IBM 2210 or IBM 2216 the main commands are:

Talk 6 (accesses the configuration interface of the IBM 2216 or IBM 2210) Protocol XXXXX Where XXXXX is the protocol to configure. Network X Where X is the network interface to configure. List (to check what parameters have been entered) Exit Command key Control P The most useful is the ? symbol, which shows you all available functions from your current position.
Examples of the above commands follow.
71
Copyright Notices: Licensed Materials - Property of IBM Multiprotocol Routing Services (C) Copyright IBM Corp. 1996, 1997 All Rights Reserved. US Gov. Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
MOS Operator Control * talk 6 Gateway user configuration Config>network network Network number [0]? 0 Token-Ring interface configuration TKR config>list all Token-Ring configuration: Packet size (INFO field): 2052 Speed: 16 Mb/sec Media: Shielded RIF Aging Timer: 120 Source Routing: Enabled MAC Address: 400022100014 IPX interface configuration record missing TKR config>exit Config>protocol Protocol name or number [IP]? IP Internet protocol user configuration IP config>add address Which net is this address for [0]? 1 New address [?] 10.1.2.2 Address mask [255.0.0.0]? 255.255.255.0 IP config>> ? LIST CHANGE DELETE DISABLE ENABLE ADD SET MOVE UPDATE EXIT
Figure 32. IBM 2210 Command Line Interface Examples
72
IP config>list all Interface addresses IP addresses for each interface: intf 0 intf 1 10.1.2.2 255.255.255.0 intf 2 intf 3 intf 4 intf 5 Routing
IP disabled on this interface Local wire broadcast, fill 1 IP disabled on this interface IP disabled on this interface IP disabled on this interface IP disabled on this interface
Protocols BOOTP forwarding: disabled IP Time-to-live: 64 Source Routing: enabled Echo Reply: enabled TFTP Server: enabled Directed broadcasts: enabled ARP subnet routing: disabled ARP network routing: disabled Per-packet-multipath: disabled OSPF: disabled BGP: disabled RIP: disabled IP config>exit Config> Crtl P *restart Are you sure you want to restart the gateway? (Yes or [No] Y
Copyright Notices: Licensed Materials - Property of IBM Multiprotocol Routing Services (C) Copyright IBM Corp. 1996, 1997 All Rights Reserved. US Gov. Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
MOS Operator Control *

Figure 33. IBM 2210 Command Line Interface Examples
73
74
Chapter 7. IBM 2210s, IBM 5394 and SDLC Relay

When migrating from an SNA/SDLC network to a multiprotocol router network, in some cases devices cannot be turned into LAN capable ones. If two devices, for example a System/36 and an IBM 5394, still need to communicate via an SNA/SDLC connection, the SDLC Relay function of the IBM 2210 and IBM 2216 routers can be used. This function supports the transport of SNA/SDLC via a multiprotocol router network. SDLC frames are imbedded into TCP/IP frames. This includes not only SDLC data frames but also the polling traffic. Data link switching is generally a better solution for the connection of SDLC devices. It provides SDLC to LLC2 conversion and prevents the transmission of SDLC polling across the wide area network connections. But DLSw is unable to support connections between two SDLC devices. The objectives of this scenario are as follows:

To connect two IBM 2210 routers using a WAN link To configure SDLC Relay to support SDLC tunneling
Figure 34 provides an overview of the IBM 2210 multiprotocol router network we established. Please note that the routers include LAN adapters (interface number 0) which are configured but not used in this scenario. TCP/IP is configured for communications between the routers.
Figure 34. IBM 2210 Router Network, SDLC Relay
75
7.1 Hardware/Software Involved
Routers IBM 2210, Model 121 (Token-ring), with MRNS V1R2 IBM 2210, Model 122 (Ethernet), with MRNS V1R2
WAN link between routers The connection speed is 64 kbps. We used IBM 5822-10 modems with V.35 interfaces.
SDLC links between routers and SDLC devices The speed of the two connections is 19200 bps. We used IBM 5812 modems.
IBM 5394 Remote Workstation Controller With microcode Release 2.3. Note that the T2.1 Node Support RPQ 8Q0775 is not required.
AS/400 system With OS/400 V3R1, OS/400 includes SNA and remote workstation controller support.
7.2 AS/400 and IBM 5394 Configuration

We configured an SDLC-leased connection between the AS/400 and the IBM 5394. The router network is fully transparent to the two devices. The IBM 2210 routers support full-duplex connections only, which we have included in the definitions. The AS/400 SDLC line, remote workstation controller and display device descriptions are as follows:
CRTLINSDLC LIND(L0625394) RSRCNAME(LIN062) ROLE(*PRI) + CNN(*NONSWTPP) DUPLEX(*FULL) CRTCTLRWS CTLD(RWS5394) TYPE(5394) MODEL(1) + LINKTYPE(*SDLC) + LINE(L0625394) EXCHID(05F00001) STNADR(01) + CRTDEVDSP DEVD(DSP3477) DEVCLS(*RMT) TYPE(3477) MODEL(FC) + LOCADR(00) CTL(RWS5394)
Please note that the SDLC Relay does not require the T2.1 Node Support RPQ.
76
0 0/ 1/ 2/ D . .
1 . . .
2 . . .
3 . . .
4 . . .
5 . . .
6 . . .
AA 0 1 00
BB 2
0 01 3 0 1 1 0 0 0 0 83C 0 P _ _
Figure 35. IBM 5394 Setup Panel
Table 14 shows the IBM 5394 configuration values selected and a description of those values.
Table 14. IBM 5394 Configuration Parameters Field /Subfield AA BB 1 2 3/1 3/2 3/3 3/4 3/5 3/6 3/7 8 P Field Description Communication Mode Operation Mode Keyboard Code SDLC Station Address Connection Type Modem Mode Link Type NRZ/NRZI Pin 20 Leading Pad Local Loopback V.25bis Autodial Configuration Printer Value Selected 0 0 00 01 0 1 1 0 0 0 0 Non-switched Full-duplex Point-to-point NRZI DTR No leading pad No loopback Not used Value Description SDLC leased 5394 Mode US English
7.3 IBM 2210 Router Configuration

The following 2210 router configuration was carried out using the ASCII console attached to the 2210. Many options are prompted for automatically by the router but not all are, so you need to be careful. For any command you can prompt for the options allowed using a ? ( question mark). We used the Quick Configuration (QCONFIG) process to build the base 2210 configuration. This base configuration was then modified as necessary.
77
7.3.1 Token-Ring Attached IBM 2210 with Serial SDLC Line - 2210TR
The configuration of 2210TR is as follows: The configuration task used is 6 Config. The Talk 6 command is used to access this task. This gives the Config> prompt. Refer to Figure 36. Talk 6 Config> QCONFIG Quick Configuration 1 Configure interfaces? > yes Intf 0 is Token Ring Speed in Mb/Sec (4,16) = [4] 4 Connector (STP, UTP) = [UTP] STP Intf 1 is WAN Frame Relay Encapsulation for WAN 1 (PPP, Frame Relay) = [Frame Relay] PPP Cable type (RS-232 modem, RS-232 direct attach, V.35 modem, V.35 direct attach, V.36, X.21) = [V.35 modem] V.35 modem Intf 2 is WAN Frame Relay Encapsulation for WAN 2 (PPP, Frame Relay) = [Frame Relay] PPP Cable type (RS-232 modem, RS-232 direct attach, V.35 modem, V.35 direct attach, V.36, X.21) = [V.35 modem] RS-232 modem This is all configured device information: Intf 0 is Token Ring, Speed 4 Mb/sec, Connector STP Intf 1 is WAN1 with PPP Encapsulation, V.35 modem cable Intf 2 is WAN2 with PPP Encapsulation, RS-232 modem cable Save this configuration? (Yes, No) = [Yes] (press enter to save) Configure bridging? (Yes, No, Quit) = [Yes] no Configure protocols? (Yes, No, Quit) = [Yes] yes Configure IP? (Yes, No) = [Yes] yes Configuring Interface 0 (Token Ring) Configure IP on this interface? (Yes, No) = [Yes] IP address : 9.24.104.178 Address mask : 255.255.255.0 Configuring Interface 1 (WAN PPP) Configure IP on this interface? (Yes, No) = [Yes] IP address : 9.67.46.162 Address mask : 255.255.255.240 Configuring Interface 2 (WAN PPP) Configure IP on this interface? (Yes, No) = [Yes] Enable dynamic routing? (Yes, No) = [Yes] no This is the information you have entered: Interface # IP Address Address Mask 0 9.24.104.178 255.255.255.0 1 9.67.46.162 255.255.255.240 Save this configuration? (Yes, No) = [Yes] (press Configure IPX? (Yes, No) = [Yes] no Configure booting? (Yes, No, Quit) = [Yes] no Enable console modem control? (Yes, No, Quit) = [Yes] no Restart the router? (Yes,No) = [Yes] (press enter to restart the router)
Figure 36. 2210 MRNS Quick Configuration - 2210TR
yes
yes
no
enter to save)
78
Talk 6 Config> network 1 PPP config> set HDLC encoding NRZI PPP config> list hdlc (to verify) Maximum frame size in bytes = 2048 Encoding: NRZI Idle State: Flag Clocking: External Cable type: V.35 DTE Internal Clock Speed: 0 Transmit Delay Counter: 0 PPP config> exit
Figure 37. 2210 MRNS WAN Configuration - 2210TR
Config> set data-link srly Interface number [0]? 2 Config> network 2 SDLC relay interface user configuration SRLY2 Config> set frame-size 1033 SRLY2 Config> set encoding NRZI SRLY2 Config> list link (to verify) Maximum frame size in bytes = 1033 Encoding: NRZI Idle State: Flag Clocking: External Cable type: RS-232 DTE Internal Clock Speed: 0 Transmit Delay Counter: 0 SRLY2 Config> exit
Figure 38. 2210 MRNS SDLC Relay Configuration 1/2 - 2210TR
Config> prot ip IP config> add route IP destination (0.0.0.0)? (press enter to accept default) Address mask (0.0.0.0)? (press enter to accept default) Via gateway at (0.0.0.0)? 9.67.46.161 Cost (1)? (press enter to accept default) IP config> list routes (to verify) route to 0.0.0.0,0.0.0.0 via 9.67.46.161, cost 1 IP config> exit
Figure 39. 2210 MRNS IP Configuration - 2210TR
79
Config> prot sdlc SDLC Relay protocol user configuration SDLC config> add group Group number: [1]? 1 SDLC config> add local-port Group number: [1]? 1 Interface number: [0]? 2 (P)rimary or (S)econdary: [S]? secondary SDLC config> add remote-port Group number: [1]? 1 IP address of remote router: [0.0.0.0]? 9.67.46.161 (P)rimary or (S)econdary: [S]? primary SDLC config> list all (to verify) SDLC config> exit
Figure 40. 2210 MRNS SDLC Relay Configuration 2/2 - 2210TR
The restart command is used (from the OPCON prompt) to read and activate the 2210 configuration. Press Ctrl + P to access the OPCON prompt (*). For example: Config> Ctrl P * restart Are you sure you want to restart the gateway? (Yes or [No])yes
For notes see page 83.
7.3.2 Ethernet-Attached IBM 2210 - 2210ETH

The configuration task used is 6 Config. The Talk 6 command is used to access this task. This gives the Config> prompt. Refer to Figure 41 on page 81.
80
Talk 6 Config> QCONFIG Quick Configuration 1 Configure interfaces? > yes Intf 0 is Ethernet Intf 1 is WAN Frame Relay Encapsulation for WAN 1 (PPP, Frame Relay) = [Frame Relay] PPP Cable type (RS-232 modem, RS-232 direct attach, V.35 modem, V.35 direct attach, V.36, X.21) = [V.35 modem] V.35 modem Intf 2 is WAN Frame Relay Encapsulation for WAN 2 (PPP, Frame Relay) = [Frame Relay] PPP Cable type (RS-232 modem, RS-232 direct attach, V.35 modem, V.35 direct attach, V.36, X.21) = [V.35 modem] RS-232 modem This is all configured device information: Intf 0 is Ethernet, Connector (10baseT, AUI) auto-configured Intf 1 is WAN1 with PPP Encapsulation, V.35 modem cable Intf 2 is WAN1 with PPP Encapsulation, RS-232 modem cable Save this configuration? (Yes, No) = [Yes] (press enter to save) Configure bridging? (Yes, No, Quit) = [Yes] no Configure protocols? (Yes, No, Quit) = [Yes] yes Configure IP? (Yes, No) = [Yes] yes Configuring Interface 0 (Ethernet) Configure IP on this interface? (Yes, No) = [Yes] IP address : 9.67.46.129 Address mask : 255.255.255.240 Configuring Interface 1 (WAN PPP) Configure IP on this interface? (Yes, No) = [Yes] IP address : 9.67.46.161 Address mask : 255.255.255.240 Configuring Interface 2 (WAN PPP) Configure IP on this interface? (Yes, No) = [Yes] Enable dynamic routing? (Yes, No) = [Yes] no This is the information you have entered: Interface # IP Address Address Mask 0 9.67.46.129 255.255.255.240 1 9.67.46.161 255.255.255.240 Save this configuration? (Yes, No) = [Yes] (press Configure IPX? (Yes, No) = [Yes] no Configure booting? (Yes, No, Quit) = [Yes] no Enable console modem control? (Yes, No, Quit) = [Yes] no Restart the router? (Yes,No) = [Yes] (press enter to restart the router)
Figure 41. 2210 MRNS Quick Configuration - 2210ETH
yes
yes
no
enter to save)
Talk 6 Config> network 1 PPP config> set HDLC encoding NRZI PPP config> list hdlc (to verify) Maximum frame size in bytes = 2048 Encoding: NRZI Idle State: Flag Clocking: External Cable type: V.35 DTE Internal Clock Speed: 0 Transmit Delay Counter: 0 PPP config> exit
Figure 42. 2210 MRNS WAN Configuration - 2210ETH
81
Config> set data-link srly Interface number [0]? 2 Config> network 2 SDLC relay interface user configuration SRLY2 Config> set frame-size 1033 SRLY2 Config> set encoding NRZI SRLY2 Config> list link (to verify) Maximum frame size in bytes = 1033 Encoding: NRZI Idle State: Flag Clocking: External Cable type: RS-232 DTE Internal Clock Speed: 0 Transmit Delay Counter: 0 SRLY2 Config> exit
Figure 43. 2210 MRNS SDLC Relay Configuration 1 of 2 - 2210ETH
Config> prot ip IP config> add route IP destination (0.0.0.0)? (press enter to accept default) Address mask (0.0.0.0)? (press enter to accept default) Via gateway at (0.0.0.0)? 9.67.46.162 Cost (1)? (press enter to accept default) IP config> list routes (to verify) route to 0.0.0.0,0.0.0.0 via 9.67.46.162, cost 1 IP config> exit
Figure 44. 2210 MRNS IP Configuration - 2210ETH
Config> prot sdlc SDLC Relay protocol user configuration SDLC config> add group Group number: [1]? 1 SDLC config> add local-port Group number: [1]? 1 Interface number: [0]? 2 (P)rimary or (S)econdary: [S]? primary SDLC config> add remote-port Group number: [1]? 1 IP address of remote router: [0.0.0.0]? 9.67.46.162 (P)rimary or (S)econdary: [S]? secondary SDLC config> list all (to verify) SDLC config> exit
Figure 45. 2210 MRNS SDLC Relay Configuration 2 of 2 - 2210ETH
The restart command is used (from the OPCON prompt) to read and activate the 2210 configuration. Press Ctrl P to access the OPCON prompt (*). For example: Config> Ctrl P * restart Are you sure you want to restart the gateway? (Yes or [No])yes
82
Notes:
1 When you power up a brand new IBM 2210 router, which has not been configured previously, you will automatically go into the QCONFIG program. This part of the configuration must always be done via the console. 2 A route with an IP destination and address mask of 0.0.0.0 defines a default route.
83
84
Chapter 8. 5494 Connectivity Using IBM 2210 APPN

The IBM 2210 and 2216 Nways multiprotocol routers have enhanced APPN support. In this simple scenario we look at how we can use the IBM 2210 APPN support to connect a remote IBM 5494 Remote Workstation Controller and a LAN to an AS/400. The objectives of this scenario are as follows:

To interconnect a remote IBM 5494 and LAN with the central AS/400 site. To connect the IBM 2210 router to the AS/400 using a WAN link. To configure native APPN in order to support SNA connectivity.
In the first section of this chapter we look at a network overview and the hardware and software involved. Following that we review the APPN network configurations for the different systems. In the last section we verify the APPN connectivity.
Figure 46. IBM 2210 APPN Gateway. 5494 and Client Access SNA Connectivity
8.1 Hardware and Software Involved
Router IBM 2210 Model 14T, with MRS V2R2 and 32 MB of memory.
WAN link between the IBM 2210 and the AS/400
85
The speed of the connection is 64 kbps. We used a modem eliminator with V.35 interfaces.
WAN link between the IBM 2210 and the IBM 5494 The speed of the connection is 19200 bps. We used a V.24 DCE cable for the 2210 and the normal V.24 5494 cable.
LAN multi-access unit IBM 8228 to build the token-ring LAN segment.
IBM 5494 Remote Workstation Controller With Release 3.2 microcode. Configured for V.24 SDLC upstream and twinax devices attached. What about the IBM 5394 When connecting an IBM 5394 to a 2210 router, the 8Q0775 microcode diskette is required. This microcode allows the 5394 to participate in an APPN network as a low-entry node. To order, contact your IBM representative or IBM authorized business partner. If you would like additional information visit the IBM 5394 home page at: http://www.networking.ibm.com/539/539prod.html or the IBM Networking home page at: http://www.networking.ibm.com The diskette image for RPQ 8Q0775 is NOT available on the Web and must be ordered via an MES order.
IBM Thinkpad Windows 95, Personal Communications and Client Access V3R1M3. Token-ring Auto 16/4 Credit Card Adapter.
AS/400 system With OS/400 V4R2.
86
8.2 The APPN Network

In our multiprotocol router network we defined APPN to support SNA traffic between the remote 5494/LAN and the central AS/400. The IBM 2210 and the AS/400 are configured as APPN network nodes (the AS/400 could also be an APPN end node in this scenario). The 5494 and Client Access are LEN nodes.
Figure 47. IBM 2210 APPN Gateway. APPN Network.
8.2.1 AS/400 Definitions

In this section we show the AS/400 APPN network definitions. For this scenario we created:

An SDLC line description An APPC controller
AS/400 Network Attributes (RALYAS4C): The AS/400 APPN node type, Network ID and CP name are defined in the system network attributes. To display the network attributes for RALYAS4C, use the command DSPNETA.
87
Display Network Attributes Current system name . . . . . . . . . . Pending system name . . . . . . . . . Local network ID . . . . . . . . . . . . Local control point name . . . . . . . . Default local location . . . . . . . . . Default mode . . . . . . . . . . . . . . APPN node type . . . . . . . . . . . . . Data compression . . . . . . . . . . . . Intermediate data compression . . . . . Maximum number of intermediate sessions Route addition resistance . . . . . . . Server network ID/control point name . . Press Enter to continue. F3=Exit F12=Cancel
Figure 48. AS/400 Network Attributes
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
: : : : : : : : : : : :
System: RALYAS4C USIBMRA RALYAS4C RALYAS4C BLANK *NETNODE *NONE *NONE 200 128 *LCLNETID
RALYAS4C
*ANY More...
From Figure 48 take note of the local network ID and local control point name. SDLC Line Description: The physical connection between an AS/400 and a network is defined using a line description . To define the SDLC line on RALYAS4C, we used the following command:
CRTLINSDLC LIND(V35LINE) RSRCNAME(CMN06) INTERFACE(*V35) LINESPEED(64000) DUPLEX(*FULL) TEXT( V35 Line to 2210 14T )
The important parameters in the SDLC line description are: Line description (LIND) The unique name for this line description. Resource name (RSRCNAME) Use the Work with Hardware Resource command with *CMN (WRKHDWRSC *CMN) to locate the resource name for the V35 adapter. APPC Controller Description: The remote system is defined using a controller description . For APPN we define an APPC controller description. To define the 2210 APPN connection controller description, we used the following command:
CRTCTLAPPC CTLD(APPN2210) LINKTYPE(*SDLC) LINE(V35LINE) RMTCPNAME(*ANY) STNADR(01) NODETYPE(*NETNODE) HPR(*NO) TEXT( APPC Controller for 2210 14T )
Note Enter the command CALL QCMD to get additional lines to allow this command to be entered.
The important parameters in the APPC controller for the 2210 are:
88
Controller description (CTLD) The unique name for the controller description. Station address (STNADR) The 2210 SDLC station address. APPN node type (NODETYPE) The 2210 will be a NETNODE in this APPN network. APPN/HPR capable (HPR) We will not use HPR in this configuration. The APPC device, Remote Workstation Controller and Remote Workstation Device descriptions are created automatically when the link to the 5494 becomes active provided that the QAUTOCFG and QAUTORMT system values are set to 1 (on).
8.2.2 IBM 5494 Definitions

We defined the IBM 5494 Remote Workstation Controller to communicate with AS/400 RALYAS4C. What about a 5394 If you are using the 5394 with 8Q0775 microcode diskette the configuration parameters and screens are the same as for the 5494.
0/ 1/ 2/ 3/
0 1 2 3 4 5 6 ---------------------------------------------------------00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AA 0 1- 00 - -
2- 10
3-
DD0 1 1 0 0 0 0
0 8060 P- -
Figure 49. IBM 5494, Setup Panel, 1 of 2
89
111519-
USIBMRA 12- RAL5494_ 13- RAL5494_ 14- QRMTWSC_ _______________ 16- 010 06 1 17- 00-00000 18________ 00001 20- 1 21- 0 22- 000 23- 0
H1:1H1:5-
RALYAS4C H1:2- USIBMRA H1:3- USIBMRA H1:4- QRMTWSC ____________________________________________________________ H1:7- 04 H1:8- 2 H1:9- 1 ________ H2:2- ________ H2:3- ________ H2:4- ________ ____________________________________________________________ H2:7- __ H2:8- _ H2:9- _ ________ H3:2- ________ H3:3- ________ H3:4- ________ ____________________________________________________________ H3:7- __ H3:8- _ H3:9- _ ________ H4:2- ________ H4:3- ________ H1:4- _______ ____________________________________________________________ H4:7- __ H4:8- _ H4:9- _
H2:1H2:5-
H3:1H3:5-
H4:1H4:5-
Figure 50. IBM 5494 Setup Panel, 2 of 2 - Connecting to RALYAS4C
Table 15 (Page 1 of 2). IBM 5494 Configuration Parameters Field /Subfield AA 1 2 3/1 3/2 3/3 3/4 3/5 3/6 3/7 8 P 11 12 13 14 15 16 17 18 19 20 Field Description Communication Mode Keyboard Code Station Address Line Type Line Facility Connection Type Data Encoding Connection Method Send Leading Pad Local Loopback Support V.25 bis Parameters Configuration Printer Network ID of 5494 LU Name of 5494 CP Name of 5494 Mode Name 5494 MAC Address Retry Parameters 5494 Serial Number 5494 System Password 5494 ID Number Primary AS/400 System 010 06 USIBMRA RAL5494 RAL5494 QRMTWSC Same as AS/400 Value Selected 0 00 10 0 1 1 0 0 0 0 060 Value Description SDLC US English Same as 2210 Leased Line Full-duplex Point-to-point NRZI
DTR 1 No 1 No 1
90
Table 15 (Page 2 of 2). IBM 5494 Configuration Parameters Field /Subfield 21 22 23 H1:1 H1:2 H1:3 H1:4 H1:5 H1:7 H1:8 H1:9 Note: Field Description Concurrent Host Attachment Concurrent Host Attachment Printer Timeout Synchronize 5494 Date and Time with Primary AS/400 AS/400 LU Name AS/400 Network ID 5494 Network ID Mode Name AS/400 MAC Address Token-Ring SAP TR Max Out TR Max In 04 2 1 RALYAS4C USIBMRA USIBMRA QRMTWSC Value Selected Value Description
1 1 1
1 Default values accepted AS/400 APPN Remote Location Configuration List An entry might be needed in the APPN Remote Locations Configuration List for location RAL5494. You can add this entry using the following command:
ADDCFGLE TYPE(*APPNRMT) APPNRMTE((RAL5494 *NETATR *NETATR *NONE APPN2210))

Or by using the command WRKCFGL.
8.2.3 Thinkpad Setup

In this section we show the Thinkpad setup for Personal Communications and Client Access V3R1M3. The objective is to reach the AS/400 for 5250 terminal emulation, to be able to use Client Access AS/400 Operations Navigator and to be able to use Windows Network Neighborhood to get access to the AS/400 Integrated File System (IFS). Personal Communications Setup: Follow these steps to set up the 5250 connection to the AS/400. 1. Open Start or Configure Session from the Personal Communication folder.
91
Figure 51. Personal Communications. Select Connection to Host.
2. Select LAN via IEEE 802.2 for the Attachment and AS/400 for the Host. 3. Press Configure .
92
Figure 52. Personal Communications. 5250 Host.
4. Select Configure Link .
Figure 53. Personal Communications. Configure Local System.
93
5. Enter the NetID and CP Name for the Thinkpad. 6. Press Next .
Figure 54. Personal Communications. Configure Logical Connection.
7. Enter the NetID and Partner LU name of the AS/400, which are the local control point name and the local network name of the AS/400 (see Figure 48 on page 88). 8. Press Next .
94
Figure 55. Personal Communications. Configure LAN Connection.
9. Enter the Destination address (token-ring). This is the token-ring address of the 2210, in this case 400022100014 (see Figure 65 on page 101). 10. Press Next .
95
Figure 56. Personal Communications. Configuration Complete.
11. Press Finish and you will be asked to save this configuration. Client Access for Windows 95/NT V3R1M3 Setup: We will now set up Client Access for the AS/400 Operations Navigator. 1. From the Client Access folder in Windows 95/NT, start AS400 Connections .
Figure 57. Client Access. New AS/400 Connection.
2. From the Connection pull-down menu select New .
96
Figure 58. Client Access. Select Personal Communications.
3. Select IBM Personal Communications as Provider. Why IBM Personal Communications If IBM Personal Communications is installed on the PC because you need to use emulators not provided by Client Access, for example 3270, you must use IBM Personal Communications instead of the NetSoft NS/Router for SNA communications. 4. Press Next .
Figure 59. Client Access. Enter System Name.
5. Enter the AS/400 CP name (see Figure 48 on page 88). 6. Press Next .
97
Figure 60. Client Access. Enter User ID.
7. Enter the Default User ID. 8. Press Next .
Figure 61. Client Access. Select Default View.
9. Select the desired default view. 10. Press Next .
98
Figure 62. Client Access. Verify Connection and Finish.
11. After verifying the connection, press Finish .
Figure 63. Client Access. AS/400 Connections.
12. This completes the Thinkpad setup.
99
8.3 IBM 2210 Configuration

In this section we show the IBM 2210 configuration using the MRS configuration program. Wherever possible we accepted the defaults. We therefore only show parameters where they had to be entered or changed.
8.3.1.1 Selecting the 2210 Model

After starting the configuration program, we must first select the 2210 model that we are building this configuration for. 1. Select and hold the mouse button on Configure . 2. Move pointer to New Configuration . 3. Move pointer to desired model. 4. Move pointer to any additional options as required.
Figure 64. Selecting the 2210 M o d e l
We selected a 2210 Model 14T with an empty slot.
100
8.3.1.2 Configuring the Interfaces

For this scenario we configured the following interfaces:

A token-ring interface An SDLC interface to the AS/400 An SDLC interface to the IBM 5494
Configuring the Token-Ring Interface: 1. From the Devices folder select Interfaces . 2. Select Configure against the token-ring interface.
Figure 65. Configuring the 2210 Token-Ring Interface
We selected:

Cable type STP Set the MAC address to 400022100014
101
Configuring the Serial SDLC Interface 1: We used serial interface 1 to connect to the AS/400. 1. Select SDLC from the drop-down list against interface 1. 2. Select Configure against serial interface 1.
Figure 66. Configuring the 2210 Serial Interface to the AS/400
From General we selected:

Encoding NRZI Cable type V.35 DTE Set the clock speed to 64000
102
Configuring Serial Interface 2: We used serial interface 2 to connect to the IBM 5494. 1. Select SDLC from the drop-down list against interface 2. 2. Select Configure against serial interface 2.
Figure 67. Configuring the 2210 Serial Interface to the I B M 5494

Encoding NRZI Cable type RS-232 DCE Clocking Internal Clock Speed 19200 MTU size 521 Note
We set the MTU value for this interface to 521 to match the 5494 default value.
103
8.3.1.3 APPN Configuration

Select General from the APPN folder.
Figure 68. 2210 General APPN Configuration
We selected:

Enable APPN network node . Set the Network ID to USIBMRA . Set the Control point name to APPN2210 .
104
Configuring the APPN Interfaces Select Interfaces from the APPN folder.
Figure 69. 2210 APPN Interface Port Selection
We selected:

Define Port for interface 0 . Define Port for interface 1 . Define Port for interface 2 . Port Configuration
For this scenario we used the default port configuration for each interface.
105
Serial Interface 1 APPN Configuration: We used serial interface 1 to connect to the AS/400. Select Link Stations against serial interface 1.
Figure 70. 2210 Link Station Configuration for Interface 1
From General-1 we set the Link station name to RALYAS4C .
106
Select General-2 to enter a station address and adjacent node type.
Figure 71. 2210 Link Station Configuration for Interface 1 Continued
From General-2 we selected:

Station address 01. Adjacent node type APPN network node . Pressed Add .
107
Interface 2 APPN Configuration: We used serial interface 2 to connect to the IBM 5494. Select Link Stations against serial interface 2.
From General-1 we:

Set the Link station name to RAL5494 . Deselected Allow CP-CP sessions on this link.
108
Select General-2 to enter a station address, adjacent node name and node type.

Station address 10. Adjacent node type LEN end node . Fully-qualified CP name USIBMRA.RAL5494 . Pressed Add .
109
8.3.1.4 Saving the Configuration

Select Configure from the Navigation Window to save the configuration and to create a file to be loaded onto the router.
Figure 74. Saving the 2210 Configuration
We selected:

Save configuration as... A Configuration name of APPN2210 in the config.cdb database. OK . Configure once more. Create router configuration... A configuration file name of APPN2210.CFG.
We then copied the file to a diskette and used the Zmodem file transfer protocol to install the configuration on the IBM 2210 via the service port.
110
8.4 Starting and Verifying the Configuration

First we must vary on (activate) the AS/400 SDLC line description and the APPC controller for the 2210. To do this, use the CL command:
VRYCFG CFGOBJ(V35LINE) CFGTYPE(*LIN) STATUS(*ON)

For a non-switched line (as in this case), the above command will also activate (vary on) the associated controller descriptions. Should it be necessary to vary on the controller separately, use the command:
VRYCFG CFGOBJ(APPN2210) CFGTYPE(*CTL) STATUS(*ON)

We can now start the Thinkpad 5250 terminal session.
Figure 75. Personal Communications. 5250 Connection to Host.
Having started the Client Access connection we can start the AS400 Operations Navigator.
111
Figure 76. Client Access. AS400 Operations Navigator.
We can now reach the IFS (Integrated File System) of the AS400 from native Windows 95/NT Network Neighborhood.
Figure 77. Client Access. Network Neighborhood.
112
The status of the SDLC line, APPC controller and APPC device can be displayed by using the CL command:
WRKCFGSTS CFGTYPE(*LIN) CFGD(V35LINE)

Work with Configuration Status 04/07/98 Position to . . . . . Starting characters RALYAS4C 12:46:06
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description V35LINE APPN2210 APPN2210 RAL5494 QRMTWSC QRMTWSC THINKPAD QPCSUPP Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE/SOURCE ACTIVE/TARGET ACTIVE ACTIVE/TARGET -------------Job--------------
RAL5494 RAL5494 QPASVRP
QUSER QUSER QSYS
067196 067196 065699 Bottom
Parameters or command ===> F3=Exit F4=Prompt F12=Cancel
F23=More options
F24=More keys
Figure 78. AS/400 SDLC Configuration Status
In Figure 78 we can see that the APPC devices APPN2210, RAL5494 and THINKPAD have been autocreated by the AS/400. The status of the remote workstation configuration can be displayed by entering the command:
WRKCFGSTS CFGTYPE(*CTL) CFGD(RAL54*)

Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description RAL54RMT RAL5DSP00 Status ACTIVE SIGNON DISPLAY -------------Job--------------
F23=More options
F24=More keys
Figure 79. AS/400 SDLC Configuration Status
In Figure 79 we can see the remote workstation controller and device descriptions that have been autoconfigured by the AS/400.
113
Autocreated Configuration Object Naming The autocreated remote workstation controller and remote workstation device descriptions will have the following naming convention:
For the remote workstation controller description, the first five characters of the 5494 control point name plus RMT (for example, RAL54RMT). For the remote workstation display device descriptions, the first four characters of the 5494 control point name plus DSPyy, where yy is a sequential number generated by the AS/400 (for example, RAL5DSP00). For the remote workstation printer device descriptions, the first four characters of the 5494 control point name plus PRTyy, where yy is a sequential number generated by the AS/400 (for example, RAL5PRT07).
The following screens were captured at the 2210 router. In Figure 80, the list cp-cp sessions command displays the APPN CP-CP sessions for which the 2210 is a partner.
*t 5 CGW Operator Console +prot appn APPN GWCON APPN >list cp-cp sessions CP Name Type Status Connwinner ID Conloser ID ======================================================================== USIBMRA.RALYAS4C NN Active B90AC73F B90AC741
Figure 80. 2210 CP-CP Sessions
In Figure 81, the list isr_sessions command displays the APPN ISR sessions that are passing through the 2210.
APPN >list isr_sessions Adjacent CP Name TG Number ISR Sessions =============================================== USIBMRA.RALYAS4C 1 2 USIBMRA.RAL5494 0 1 USIBMRA.THINKPAD 0 1
Figure 81. 2210 ISR Sessions
114
In Figure 82, the list link_information command displays the 2210 APPN links.
APPN >list link_information Name Port Name Intf Adj CP Name Type HPR State ========================================================================= RALYAS4C SDLC001 1 USIBMRA.RALYAS4C NN INACTIVE ACT_LS RAL5494 SDLC002 2 USIBMRA.RAL5494 EN INACTIVE ACT_LS @@0 TR000 0 USIBMRA.THINKPAD EN INACTIVE ACT_LS APPN >
Figure 82. 2210 Link Information
115
116
Chapter 9. IBM 2210 Frame Relay Connectivity to an AS/400

Frame relay networks allow for high speed multiprotocol connectivity. The AS/400 s support for RFC1490 can be used in conjunction with the IBM 2210/2216 Boundary Access Node support to provide direct multiprotocol connectivity between an AS/400 and remote IBM 2210/2216 networks. The objectives of this scenario are as follows:

To interconnect a remote LAN with the central AS/400 site. To connect the IBM 2210 router with the AS/400 using a frame relay WAN link. To configure native APPN, TCP/IP and IPX protocols.
In the first section of this chapter we look at a network overview and the hardware and software involved. Following that we review the network from the different views of the three protocols running across it. The views we look at are as follows:

APPN network to support SNA connections TCP/IP network IPX network
We then look at the router definitions required. In the last section we verify connectivity for the different protocols being used.
Figure 83. Frame Relay High Speed 5494, Client Access, IP and IPX Connectivity
117
Router IBM 2210 Model 14T, with MRS V2R2 and 32 MB of memory.
Frame relay WAN link between the IBM 2210 and the AS/400 The speed of the connection is 64 kbps. We used a modem eliminator with V.35 interfaces.
WAN Link between the IBM 2210 and the IBM 5494 The speed of the connection is 19200 bps. We used a V.24 DCE cable for the 2210 and the normal V.24 5494 cable.
LAN multi-access unit IBM 8228 to build the token-ring LAN segment.
IBM Thinkpad Windows 95, Personal Communications and Client Access V3R1M3. Token-Ring Auto 16/4 Credit Card Adapter.
118

In our multiprotocol router network we defined APPN to support SNA traffic between the remote 5494/LAN and the central AS/400. The IBM 2210 and the AS/400 are configured as APPN network nodes. The 5494 and Client Access are LEN nodes. Figure 84 shows the APPN network including the network ID and CP names.
Figure 84. Frame Relay Connectivity to AS/400. APPN Network.
9.2.1 AS/400 APPN Definitions


A token-ring line description A frame relay network interface description A frame relay line description
AS/400 Network Attributes: The AS/400 APPN node type, Network ID and CP name are defined in the system network attributes. To display the network attributes for RALYAS4C, use the command DSPNETA.
119
Figure 85. AS/400 Network Attributes
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
: : : : : : : : : : : :
RALYAS4C
*ANY More...
From Figure 85 take note of the local network ID and local control point name. Token-Ring Line Description: For token-ring, the physical connection between an AS/400 and a network is defined using a line description . To define the token-ring line on RALYAS4C, we used the following command:
CRTLINTRN LIND(TRN2619C) RSRCNAME(CMN02) LINESPEED(16M) MAXFRAME(1994) ADPTADR(400052005019) TEXT( Token Ring Line - CMN02 ) AUTOCRTCTL(*YES)
The important parameters in the token-ring line description are: Line description (LIND) The unique name for this line description. Resource name (RSRCNAME) Use the Work with Hardware Resource command with *CMN (WRKHDWRSC *CMN) to locate the resource name for the token-ring adapter. Line speed (LINESPEED) Specifies the line speed in bits per second (bps). Local adapter address (ADPTADR) Specifies the local system s token-ring adapter address. The APPC controller, APPC device, remote workstation controller and the remote workstation device descriptions are created automatically on a token-ring connection when the link with the client(s) and AS/400 becomes active provided that the QAUTOCFG and QAUTORMT system values are set to 1 (on) and the AUTOCRTCTL parameter in the token-ring line description is set to *YES. Frame Relay Network Interface Description: For frame relay, the frame relay interface description defines the AS/400 s physical interface to the network. To define the frame relay interface on RALYAS4C, we used the following command:
120
CRTNWIFR NWID(FR_RELAY) RSRCNAME(CMN10) NRZI(*YES) INTERFACE(*V35) LINESPEED(64000) LMIMODE(*NONE) TEXT( Frame Relay Network Interface on CMN10 )
The important parameters in the frame relay interface description are: Network interface description (NWID) The unique name for this network interface description Resource name (RSRCNAME) Use the Work with Hardware Resource command with *CMN (WRKHDWRSC *CMN) to locate the resource name for the frame relay adapter. NRZI data encoding (NRZI) Specifies whether non-return-to-zero-inverted (NRZI) data encoding is used for this connection. Physical interface (INTERFACE) Specifies the type of physical interface on the input/output adapter (IOA) port. LMI mode (LMIMODE) Specifies whether the local management interface (LMI) for this adapter is configured as terminal equipment, a frame handler or *NONE. LMI We used *NONE because the AS/400 and the 2210 are connected back-to-back. We did not have a frame relay network between the two.
Frame Relay Line Description for APPN: For frame relay, the line description allocates a protocol to a physical frame relay DLCI. To define the frame relay line on RALYAS4C that is to be used for APPN, we used the following command:
CRTLINFR LIND(FR_4_APPN) NWI(FR_RELAY) NWIDLCI(444) TEXT( Frame relay line for APPN on DLCI 444 )
The important parameters for the frame relay line description are: Line description (LIND) The unique name for this line description. Attached NWI (NWI) Specifies the frame relay network interface description to which this line attaches.
DLC identifier (NWIDLCI) Specifies the network interface data link connection identifier (DLCI) to be used. This would normally be supplied by the frame relay network provider. APPC Controller Description: The remote APPN node is defined using a controller description . For APPN we define an APPC controller description. To define the 2210 APPN connection, we used the following command:
121
CRTCTLAPPC CTLD(APPN2210) LINKTYPE(*FR) SWTLINLST(FR_4_APPN) RMTCPNAME(APPN2210) NODETYPE(*NETNODE) HPR(*NO) TEXT( APPC Controller for 2210 14T ) SWTDSC(*NO)
The important parameters in the APPC controller for the 2210 are: Controller description (CTLD) The unique name for the controller description. Switched line list (SWTLINLST) Specifies the names of the switched lines to which this controller can attach. Remote control point (RMTCPNAME) Specifies the remote control point name of the 2210. APPN node type (NODETYPE) The 2210 will be a NETNODE in this APPN network. APPN/HPR capable (HPR) We will not use HPR in this configuration. Switched disconnect (SWTDSC) We set this parameter to *NO to prevent the connection from being dropped when the last device is varied off. The APPC device, remote workstation controller and remote workstation device descriptions are created automatically when the links become active provided that the QAUTOCFG and QAUTORMT system values are set to 1 (on).

We defined the IBM 5494 remote workstation controller to communicate with AS/400 RALYAS4C. What about a 5394 If you are using the 5394 with 8Q0775 microcode diskette the configuration parameters and screens are the same as for the 5494.
122
0/ 1/ 2/ 3/
0 1 2 3 4 5 6 ---------------------------------------------------------00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AA 0 1- 00 - -
2- 10
3-
DD0 1 1 0 0 0 0
0 8060 P- -
111519-
H1:1H1:5-
H2:1H2:5-
H3:1H3:5-
H4:1H4:5-
Figure 87. IBM 5494 Setup Panel, 2 of 2 - Connecting to RALYAS4A
Table 16 (Page 1 of 2). IBM 5494 Configuration Parameters Field /Subfield AA 1 2 3/1 3/2 Field Description Communication Mode Keyboard Code Station Address Line Type Line Facility Value Selected 0 00 10 0 1 Leased Line Full-duplex Value Description SDLC US English
123
Table 16 (Page 2 of 2). IBM 5494 Configuration Parameters Field /Subfield 3/3 3/4 3/5 3/6 3/7 8 P 11 12 13 14 15 16 17 18 19 20 21 22 23 H1:1 H1:2 H1:3 H1:4 H1:5 H1:7 H1:8 H1:9 Note: Field Description Connection Type Data Encoding Connection Method Send Leading Pad Local Loopback Support V.25 bis Parameters Configuration Printer Network ID of 5494 LU Name of 5494 CP Name of 5494 Mode Name 5494 MAC Address Retry Parameters 5494 Serial Number 5494 ID Number 5494 ID Number Primary AS/400 System Concurrent Host Attachment Concurrent Host Attachment Printer Timeout Synchronize 5494 Date and Time with Primary AS/400 AS/400 LU Name AS/400 Network ID 5494 Network ID Mode Name AS/400 MAC Address Token-Ring SAP TR Max Out TR Max In 04 2 1 RALYAS4C USIBMRA USIBMRA QRMTWSC 010 06 USIBMRA RAL5494 RAL5494 QRMTWSC Same as AS/400 Value Selected 1 0 0 0 0 060 Value Description Point-to-point NRZI
DTR 1 No 1 No 1
1 1 1
1 Default values accepted
124
AS/400 APPN Remote Location Configuration List An entry might be needed in the APPN Remote Locations Configuration List for location RAL5494. You can add this entry using the following command:
ADDCFGLE TYPE(*APPNRMT) APPNRMTE((RAL5494 *NETATR *NETATR *NONE APPN2210))

9.2.3 Thinkpad Setup

In this section we show the Thinkpad setup for Personal Communications and Client Access V3R1M3. The objective is to reach the AS/400 for 5250 terminal emulation, to be able to use Client Access AS/400 Operations Navigator and to be able to use Windows Network Neighborhood to get access to the AS/400 Integrated File System (IFS). Personal Communications Setup: Follow these steps to set up the 5250 connection to the AS/400. 1. Open Start or Configure Session from the Personal Communications folder.
125
126
7. Enter the NetID and Partner LU name of the AS/400. This is the local control point name and the local network name of the AS/400 (see Figure 85 on page 120). 8. Press Next .
127
9. Enter the Destination address (token-ring). This is token-ring address of the 2210, in this case 400022100014 (see Figure 104 on page 140). 10. Press Next .
128
11. Press Finish and you will be asked to save this configuration. Client Access for Windows 95/NT V3R1M3 Setup: We will now set up Client Access for the AS/400 Operations Navigator. 1. From the Client Access folder in Windows 95/NT, start AS400 Connections .
129
130
7. Enter the Default User ID. 8. Press Next .
131
12. This completes the Thinkpad Setup.
132
9.3 The TCP/IP Network

In our multiprotocol router network we defined TCP/IP to support TCP/IP traffic between the remote IP client and a central IP host. Figure 101 shows the TCP/IP network including the network addresses.
Figure 101. Frame Relay Connectivity to AS/400. TCP/IP Network.
9.3.1 AS/400 TCP/IP Definitions

In this section we show the AS/400 TCP/IP network definitions. For this scenario we created:

A frame relay line description TCP/IP interfaces TCP/IP routes Token-Ring Line Description and Frame Relay Network Interface
The token-ring line description and frame relay network interface to be used were created in Token-Ring Line Description on page 120 and Frame Relay Network Interface Description on page 120. These are shared resources.
Frame Relay Line Description for TCP/IP: To define the frame relay line on RALYAS4C that is to be used for TCP/IP, we used the following command:
133
CRTLINFR LIND(FR_4_TCPIP) NWI(FR_RELAY) NWIDLCI(333) TEXT( Frame Relay Line for TCP/IP on DLC 333 )
DLC identifier (NWIDLCI) Specifies the network interface data link connection identifier (DLCI) to be used. This would normally be supplied by the frame relay network provider. TCP/IP Interface Definitions: We created two TCP/IP interfaces on RALYAS4C: 9.24.104.162 10.1.2.1 This is the local LAN interface. This is the WAN frame relay interface.
To define the token-ring TCP/IP interface on RALYAS4C, we used the following command:
ADDTCPIFC INTNETADR(9.24.104.162) LIND(TRN2619C) SUBNETMASK(255.255.255.0)

To define the frame relay TCP/IP interface on RALYAS4C, we used the following command:
ADDTCPIFC INTNETADR( 1 0 . 1 . 2 . 1 ) LIND(FR_4_TCPIP) SUBNETMASK(255.255.255.0)

What about the controller and device descriptions for TCP/IP? The controller and device descriptions will be autocreated by the system when the respective interfaces are activated.
TCP/IP Route Definitions: We created two TCP/IP routes on RALYAS4C: *DFTROUTE 10.1.3.0 This is the default route, and points to a router on the local LAN. This is the remote TCP/IP network, so requests for this network are directed to the 2210 frame relay interface.
To define the default TCP/IP route on RALYAS4C, we used the following command:
ADDTCPRTE RTEDEST( *DFTROUTE ) SUBNETMASK( *NONE ) NEXTHOP(9.24.104.1)

To define the route to the remote TCP/IP network, we used the following command:
ADDTCPRTE RTEDEST( 1 0 . 1 . 3 . 0 ) SUBNETMASK(255.255.255.0) NEXTHOP( 1 0 . 1 . 2 . 2 )
134
RouteD AS/400 RouteD is not supported for frame relay connections. We could not, therefore, use this to locate the 10.1.3.0 network and hence the static route defined above.
9.3.2 Thinkpad Setup for TCP/IP

The Thinkpad Windows 95 TCP/IP was configured as follows: IP Address Subnet Mask Default Gateway 10.1.3.47 255.255.255.0 10.1.3.1 This points to the 2210 token-ring interface.
9.3.3 IP Host TCP/IP Configuration

The IP host TCP/IP was configured as follows: IP Address Subnet Mask Route to 10.1.3.0 9.24.104.121 255.255.255.0 9.24.104.162 This points to the AS/400 token-ring interface.
135
9.4 The IPX Network

In our multiprotocol router network we defined IPX to support IPX traffic between the remote Novell client and a central Novell host. Figure 102 shows the IPX network including the network addresses.
Figure 102. Frame Relay Connectivity to AS/400. IPX Network.
9.4.1 AS/400 IPX Definitions

In this section we show the AS/400 IPX network definitions. For this scenario we created:

A frame relay line description An IPX description An IPX circuit Token-ring line description and frame relay network interface
The token-ring line description and frame relay network interface to be used were created in Token-Ring Line Description on page 120 and Frame Relay Network Interface Description on page 120. These are shared resources.
Frame Relay Line Description for IPX: For frame relay, the line description allocates a protocol to a physical frame relay DLCI. To define the frame relay line on RALYAS4C that is to be used for IPX, we used the following command:
136
CRTLINFR LIND(FR_4_IPX) NWI(FR_RELAY) NWIDLCI(555) TEXT( Frame Relay Line for IPX on DLC 555 )
DLC identifier (NWIDLCI) Specifies the network interface data link connection identifier (DLCI) to be used. This would normally be supplied by the frame relay network provider. IPX Description: The IPX description is a required object and defines global (system wide) IPX configuration values. To define the IPX description on RALYAS4C, we used the following command:
CRTIPXD IPXD(RALYAS4C) IPXNETNBR(96AD0D47) IPXRTRNAME(RALYAS4C) TEXT( IPX Description for RALYAS4C )

The important parameters in an IPX description are: IPX description (IPXD) We used the system name for the IPX description name. IPX internal network number (IPXNETNBR) The IPX network number used for the AS/400 s internal IPX network must be unique to all other network numbers (internal and external) in this IPX internetwork. Contact the network administrator for the network number to use. IPX Circuit: An IPX circuit must be defined for each line over which IPX routing will be used. What is an IPX circuit? An IPX circuit is a logical representation of a path for IPX communication. Circuits are not physical objects. Each circuit is associated with a line description. The line description describes the physical connection from the AS/400 to the network. The circuit defines the logical path from the IPX protocol layer to the line. A line description is a shared configuration object; a previously created line description can be used for IPX also.
We created two IPX circuits on RALYAS4C: Token-ring Frame relay This circuit defines the logical IPX connection to the token-ring. This circuit defines the logical IPX connection to the frame relay network connection to the 2210.
To define the token-ring IPX circuit on RALYAS4C, we used the following command:
137
ADDIPXCCT CCTNAME(TRN2619C) LIND(TRN2619C) IPXNETNBR(00000009)

To define the frame relay IPX circuit on RALYAS4C, we used the following command:
ADDIPXCCT CCTNAME(FR_4_IPX) LIND(FR_4_IPX) IPXNETNBR(00000BBB) ENBNLSP(*NO) ENBIW2(*NO)

The important parameters in the IPX circuits are: Circuit name (CCTNAME) We used the line description name for the circuit name Line description (LIND) This is the line description associated with the circuit. IPX network number (IPXNETNBR) This parameter defines the external network number for this LAN/WAN connection. Consult your network administrator to determine the value to be used. Attention If there are devices on the network that are broadcasting the wrong network number, the IPX circuit won t start. You can check the Novell server system console for messages relating to this. Enable for NSLP(ENBNLSP) The 2210 does not support NLSP at the release level we are using. We have therefore disabled NLSP for this link. Enable for IW2 (ENBIW2) We have also disabled IPX WAN Version 2 negotiations for this link. The 2210 does not support IW2 either. Since we have configured the circuits to allow NLSP and SAP to flow (the default settings), we do not have to configure IPX circuit routes or IPX circuit services. What about the controller and devices descriptions for IPX? The controller and device descriptions will be created by the system when the relevant circuit is started.
Need more info? You can find more information on AS/400 IPX in the AS/400 in the redbook Using the AS/400 as an IPX Router , SG24-4736.
138


139


A token-ring interface A frame relay interface to the AS/400 An SDLC interface to the IBM 5494
Configuring the Token-Ring Interface 1. From the Devices folder select Interfaces . 2. Select Configure against the token-ring interface.
We selected:

140
Configuring the Serial Frame Relay Interface 1: We used serial interface 1 to connect to the AS/400. 1. Select Frame Relay from the drop-down list against interface 1. 2. Select Configure against serial interface 1.

Encoding NRZI Cable type V.35 DTE
141
Select LMI to configure the frame relay LMI type.
Figure 106. Configuring the 2210 Frame Relay LMI
By default the LMI box is checked, so we unchecked this box as we were not using a real frame relay network.
142
Select PVC to configure the frame relay PVCs.
Figure 107. Configuring the 2210 Frame Relay PVCs
We added:

Circuit Number 333 with the Circuit name IP . Circuit Number 444 with the Circuit name APPN . Circuit Number 555 with the Circuit name IPX . Pressed Add after each selection.
143
Select Protocols to configure the protocol to be used over each of the configured frame relay circuits.
Figure 108. Configuring the 2210 Frame Relay Protocols
We added:

Protocol IP to Circuit Number 333 with an address of 10.1.2.2. Protocol IPX to Circuit Number 555 with an IPX host number of 96AD0D470000. Pressed Add after selection. IPX host number
As the 2210 is directly connected to the AS/400, and does not support IW2 which allows IPXWAN over a frame relay link, a static route must be provided for IPX. This static route would normally point to a remote node address (48 bits long) on the frame relay network. The AS/400 does not allow the configuration of node addresses, so the AS/400 internal IPX network number is appended with four zeros (0000) to create a pseudo node number.
144

145
9.5.1.3 IP Configuration
For this scenario we configured IP on the following interfaces:

The token-ring interface The frame relay interface to the AS/400
We also added a default route. Configuring the Token-Ring Interface IP Address 1. Select Interfaces from the IP folder. 2. Select IP Addresses against token-ring interface 0.
Figure 110. Token-Ring Interface IP Address 2210 Configuration
We entered:

An IP address of 10.1.3.1 with a subnet mask of 255.255.255.0. Pressed Add .
146
Configuring the Frame Relay Interface IP Address Select IP Addresses against frame relay interface 1.
Figure 111. IP Configuration for the 2210 Frame Relay Interface
We entered:

147
Configuring a Default IP Route Select Static Routes from the IP folder.
Figure 112. IP Configuration for the 2210 Static Routes
We added the following static route: Destination network 0.0.0.0 with a Destination mask of 0.0.0.0 and Next hop address 10.1.2.1 to define a default route to the AS/400 s frame relay interface.
148
9.5.1.4 IPX Configuration

For this scenario we configured IPX on the following interfaces:

The token-ring interface The frame relay interface to the AS/400
We also set the 2210 IPX host address. Configuring the IPX Host Number Select General from the IPX folder.
Figure 113. Configuring the 2210 General IPX Parameters
We selected:

Enable IPX . Entered a Host number of 000000221014.
149
Configuring IPX on the Token-Ring Interface 1. Select Interfaces from the IPX folder. 2. Check Enabled against token-ring interface 0. 3. Select Configure against token-ring interface 0.
Figure 114. Configuring IPX o n the 2210 Token-Ring Interface
We entered an IPX network number of 221014. IPX network number The IPX network number used must be unique to all other network numbers (internal and external) in this IPX internetwork. Contact the network administrator for the network number to use.
150
Configuring IPX on the Frame Relay Interface 1. Check Enabled against the frame relay interface 1. 2. Select Configure against the frame relay interface 1.
Figure 115. Configuring IPX o n the 2210 Frame Relay Interface
We entered an IPX network number of BBB . IPX network number The IPX network number used must be unique to all other network numbers (internal and external) in this IPX internetwork. Contact the network administrator for the network number to use.
151

We selected:

Enable APPN network node . Set the Network ID to USIBMRA . Set the Control point name to APPN2210 .
152
We selected:

Define Port for interface 0 . Define Port for interface 1 . Define Port for interface 2 .
153
Frame Relay Port 1 Configuration Select Configure against frame relay interface 1.
Figure 118. 2210 APPN Port Configuration for the Frame Relay Interface
We de-selected HPR for this interface. APPN Port 0 and 2 Configuration For this scenario we used the default port configuration for these interfaces.
154
Serial interface 2 APPN Configuration: We used the serial interface 2 to connect to the IBM 5494. Select Link Stations against serial interface 2.
Figure 119. Link Station Configuration for 2210 Interface 2
From General-1 we:

Set the Link station name to RAL5494 . De-selected Allow CP-CP sessions on this link.
155
Figure 120. Link Station Configuration for 2210 Interface 2 Continued

Station address 10 (see Figure 86 on page 123). Adjacent node type LEN end node . Fully-qualified CP name USIBMRA.RAL5494 (see Figure 87 on page 123). Pressed Add .
156
Interface 1 APPN Configuration: We used the serial interface 1 to connect to the AS/400. 1. Select FR PVC Stations from the APPN folder. 2. Select Link Stations against PVC 444.
From General-1 we selected a Link station name of RALYAS4C .
157
Select General-2 to enter the adjacent node name and node type.

Adjacent node type APPN network node . Pressed Add .
158

Select Configure from the Navigation Window to save the configuration and to create a file to be loaded on to the router.
We selected:

Save configuration as... A Configuration name of APPN2210 in the config.cdb database. OK . Configure once more. Create router configuration... A configuration file name of APPN2210.CFG .
159
9.6 Starting and Verifying the Configurations

Before we can start the APPN, IP and IPX protocols on the AS/400, we have to vary on (activate) the frame relay network interface, frame relay line and the token-ring line descriptions. To vary on the frame relay interface on RALYAS4C, we used the following command:
VRYCFG CFGOBJ(FR_RELAY) CFGTYPE(*NWI) STATUS(*ON)

The above command will also activate (vary on) the associated line descriptions. Should it be necessary to vary on the line descriptions separately, we can use the following commands:
VRYCFG CFGOBJ(FR_4_APPN FR_4_TPCIP FR_4_IPX) CFGTYPE(*LIN) STATUS(*ON) VRYCFG CFGOBJ(TRN2619C) CFGTYPE(*LIN) STATUS(*ON)
9.6.1 Starting and Verifying the APPN Network

To start the APPN session between RALYAS4C and the 2210, we used the following command to vary on (activate) the APPC controller description:
VRYCFG CFGOBJ(APPN2210) CFGTYPE(*CTL) STATUS(*ON)

Now we can start the SNA 5250 session between the Thinkpad and the AS/400 RALYAS4C.
160
And starting the Client Access connection will start the AS/400 Operations Navigator.
161
We can now use the Client Access connection to reach the AS/400 IFS (Integrated File System) using the native Windows 95/NT Network Neighborhood.
The APPC devices for the 2210 CP session, the Thinkpad APPN session and the 5494 remote workstation controller will be autocreated by the AS/400 when these sessions become active. We can see the status of the AS/400 frame relay interface and associated configuration objects using the command:
WRKCFGSTS CFGTYPE(*NWI) CFGD(FR_RELAY)
162
RALYAS4C 13:03:02
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FR_RELAY FR_4_APPN APPN2210 APPN2210 RAL5494 QRMTWSC QRMTWSC THINKPAD QPCSUPP Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE/TARGET ACTIVE/SOURCE ACTIVE ACTIVE/TARGET -------------Job--------------
QUSER QUSER QSYS
068120 068120 068124
F23=More options
F24=More keys
Figure 127. Work with Configuration Status. APPN Configuration.
In Figure 127 we can see the APPC devices APPN2210, THINKPAD and RAL5494 that have been autoconfigured by the AS/400. We can see the status of the AS/400 remote workstation controller and associated configuration objects using the command:

F23=More options
F24=More keys
Controller.
Figure 128. Work with Configuration Status. Remote Workstation.
In Figure 128 we can see the remote workstation controller and device descriptions that have been autoconfigured by the AS/400.
163
Autocreated configuration object naming The autocreated remote workstation controller and remote workstation device descriptions will have the following naming convention:
The following screens were captured at the 2210 router. In Figure 129, the list cp-cp sessions command displays the APPN CP-CP sessions for which the 2210 is a partner.
*t 5 CGW Operator Console +prot appn APPN GWCON APPN >list cp-cp sessions CP Name Type Status Connwinner ID Conloser ID ======================================================================== USIBMRA.RALYAS4C NN Active B90BDF3E B90BDF40
APPN >list isr_sessions Adjacent CP Name TG Number ISR Sessions =============================================== USIBMRA.RALYAS4C 1 2 USIBMRA.RAL5494 0 1 USIBMRA.THINKPAD 0 1
164
In Figure 131, the list link_information command displays the 2210 APPN links.
APPN >list link_information Name Port Name Intf Adj CP Name Type HPR State ========================================================================= RALYAS4C FR001 1 USIBMRA.RALYAS4C NN INACTIVE ACT_LS RAL5494 SDLC002 2 USIBMRA.RAL5494 EN INACTIVE ACT_LS @@0 TR000 0 USIBMRA.THINKPAD EN INACTIVE ACT_LS APPN >
Figure 131. 2210 Link Information
9.6.2 Starting and Verifying the TCP/IP Network

To start the token-ring TCP/IP interface on RALYAS4C, we used the following command:
STRTCPIFC INTNETADR(9.24.104.162)
To start the frame relay TCP/IP interface on RALYAS4C, we used the following command:
STRTCPIFC INTNETADR( 1 0 . 1 . 2 . 1 )
10.1.2.1 interface not started You will receive this message if the TCP/IP support is not started on the AS/400. You can start TCP/IP on the system with the STRTCP command.
Starting a TCP/IP interface creates a *NET controller and a *NET device description under the relevant line description. We used the WRKCFGSTS CFGTYPE(*NWI) CFGD(FR_RELAY) command on RALYAS4C to verify this.
165
RALYAS4C 13:04:06
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FR_RELAY FR_4_TCPIP FR_4_NET FR_4_TCP FR_4_APPN APPN2210 APPN2210 RAL5494 QRMTWSC QRMTWSC THINKPAD QPCSUPP FR_4_IPX Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE/TARGET ACTIVE/SOURCE ACTIVE ACTIVE/TARGET VARY ON -------------Job--------------
QTCPIP
QTCP
068975
QUSER QUSER QSYS
068120 068120 068124
F23=More options
F24=More keys
Figure 132. Work with Configuration Status. TCP/IP Configuration.
We checked the status of the TCP/IP interfaces with the NETSTAT *IFC command.
Work with TCP/IP Interface Status System: Type options, press Enter. 5=Display details 8=Display associated routes 9=Start 10=End 12=Work with configuration status 14=Display multicast groups Internet Address 9.24.104.162 10.1.2.1 127.0.0.1 Network Address 9.24.104.0 10.1.2.0 127.0.0.0 Line Description TRN2619C FR_4_TCPIP *LOOPBACK Interface Status Active Active Active RALYAS4C
Opt
F3=Exit F4=Prompt F13=Sort by column
F5=Refresh F11=Display line information F24=More keys
Bottom F12=Cancel
Figure 133. Work with TCP/IP Interface Status
Finally, we verified the TCP/IP connection between the remote IP client and the central IP host using FTP.
166
C:\>ftp 9.24.104.121 IBM TCP/IP for OS/2 - FTP Client ver 08:36:08 on Jul 22 1996 Connected to 9.24.104.121. 220-QTCP at 9.24.104.121. 220 Connection will close if idle more than 5 minutes. Name (9.24.104.121): mick 331 Enter password. Password: ....... 230 MICK logged on.
Figure 134. Using FTP to Verify the Connection
The following screen was captured at the 2210 router. In Figure 135, the dump command displays the 2210 TCP/IP route table.
*t 5 CGW Operator Console +p ip IP>dump Type Dest net Stat* Sbnt Dir* Dir* 0.0.0.0 10.0.0.0 10.1.2.0 10.1.3.0
Mask 00000000 FF000000 FFFFFF00 FFFFFF00
Cost 1 1 1 1
Age 398 341 398 363
Next hop(s) 10.1.2.1 None FR/0 TKR/0
Default gateway in use. Type Cost Age Next hop Stat 1 398 10.1.2.1 Routing table size: 768 nets (52224 bytes), 4 nets known 0 nets hidden, 0 nets deleted, 0 nets inactive 0 routes used internally, 764 routes free IP>
Figure 135. 2210 TCP/IP Route Information
9.6.3 Starting and Verifying the IPX Network

First we must start IPX, and on RALYAS4C we used the following command to do this:
STRIPX IPXD(RALYAS4C)
The above command will also start the token-ring and frame relay IPX circuits. Should it be necessary to start the circuits separately, use the following commands.
STRIPXCCT CCTNAME(TRN2619C) STRIPXCCT CCTNAME(FR_4_IPX)

Starting an IPX circuit creates a *NET controller and a *NET device description under the relevant line description. For the frame relay interface on RALYAS4C we used the WRKCFGSTS CFGTYPE(*NWI) CFGD(FR_RELAY) command to verify this.
167
RALYAS4C 13:13:12
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FR_RELAY FR_4_TCPIP FR_4_NET FR_4_TCP FR_4_APPN APPN2210 APPN2210 RAL5494 QRMTWSC QRMTWSC THINKPAD QPCSUPP FR_4_IPX FR_4_NET00 FR_4_IPX Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE/TARGET ACTIVE/SOURCE ACTIVE ACTIVE/TARGET ACTIVE ACTIVE ACTIVE -------------Job--------------
QTCPIP
QTCP
068975
QUSER QUSER QSYS
068120 068120 068124
QIPX
QSYS
068106
F23=More options
F24=More keys
Figure 136. Work with Configuration Status. IPX Configuration.
We then used the WRKIPXCCT command to verify the status of the IPX circuits.
Work with IPX Circuits System: Type options, press Enter. 1=Add 2=Change 4=Remove 8=Display associated routes Circuit Name FR_4_IPX TRN2619C 5=Display 9=Start Line Description FR_4_IPX TRN2619C RALYAS4C
7=Display associated services 10=End Line Type *FR *TRLAN Circuit Status Active Active
Opt
F3=Exit
F5=Refresh
F6=Print list
F12=Cancel
F17=Top
F18=Bottom
Figure 137. Work with IPX Circuits
168
The WRKIPXSTS command option 3 can be used to verify the IPX service information.
Display IPX Service Information System: Number of services . . . . . . . . . . . . . : 6 RALYAS4C
Type options, press Enter. 5=Display details Service name MICKS_SERVER MICKS_DIR________> MICKS_SERVER NSTATIONSERVER!A5> IBM8235_32C00A IBM8235_A2470E Service Type *FILESVR 026B 026B 064E 0751 0751 Remote Network 305C227F6 305C227F6 305C227F6 00000009 00000009 00000009 Hops to Service 1 1 1 1 1 1 Service Source *SAP *SAP *SAP *SAP *SAP *SAP
Opt
F3=Exit
F5=Refresh
F6=Print list
F12=Cancel
F17=Top
F18=Bottom
Figure 138. Work with IPX Services Information
In Figure 138 we can see the IPX service information from servers on the network. We can now start a Novell client.
169
A:\NWCLIENT>lsl NetWare Link Support Layer v2.14 (941011) (C) Copyright 1990-1994 Novell, Inc. All Rights Reserved. The configuration file used was A:\NWCLIENT\NET.CFG . Max Boards 4, Max Stacks 4 A:\NWCLIENT>tokencs IBM Token-Ring MLID v1.29 (941007) (C) Copyright 1993 - 1994 IBM Corporation.
All Rights Reserved.
TOKENCS-DOS-200: Inserting into the ring. Please Wait. Int 2, Port A20, Mem D0000, Mem D8000, Node Address 8005AE475B9 M Max Frame 4210 bytes, Line Speed 16 Mbps Board 1, Frame TOKEN-RING, MSB Mode A:\NWCLIENT>ipxodi NetWare IPX/SPX Protocol v3.01 (941031) (C) Copyright 1990-1994 Novell, Inc. All Rights Reserved. IPX RETRY COUNT 50 Bound to logical board 1 (TOKENCS) : Protocol ID E0 A:\NWCLIENT>route NetWare Source Routing Driver v2.21 (940315) (C) Copyright 1993 Novell Inc. All Rights Reserved. ROUTE-DOS-200: Current ROUTE.com parameters for Board #1 are: DEFault Node (Unknown) Addresses are sent SINGLE ROUTE Broadcast. Broadcast (FFFF FFFF FFFF) Addresses are sent SINGLE ROUTE Broadcast. Multicast (C000 xxxx xxxx) Addresses are sent SINGLE ROUTE Broadcast. Maximum HOPS = 7 Bridges; NODES = 16; Aging TIME = 10 Seconds. This Ring Only (TRO) Count = 0; Extra Transmit (XTX) Count = 2. A:\NWCLIENT>vlm VLM.EXE - NetWare virtual loadable module manager (C) Copyright 1994 Novell, Inc. All Rights Reserved. Patent pending.
v1.20 (941108)
The VLM.EXE file is pre-initializing the VLMs............. The VLM.EXE file is using extended memory (XMS). You are attached to server MICKS_SERVER A:\NWCLIENT>
Figure 139. IPX Logon
170
The following screens were captured at the 2210 router. In Figure 140, the dump command displays the 2210 IPX route table.
*t 5 +p ipx IPX>dump 5 route entries used out of 32 5 net entries used out of 32 Type Dir Dir RIP RIP RIP IPX> Dest net BBB 221014 9 305C27F6 96AD0D47 Hops 0 0 1 2 1 Delay 2 1 117 118 117 Age(M:S) 0: 0 0: 0 0:55 0:55 0:55 via Router BBB/000000221014 1-FR/0 221014/400022100014 0-TKR/0 BBB/96AD0D470000 BBB/96AD0D470000 BBB/96AD0D470000
Figure 140. 2210 IPX Route Information
In Figure 141, the slist command displays the 2210 IPX service information.
IPX>slist State Typ Service Name SAP 751 IBM8235_A2470E SAP 751 IBM8235_32C00A SAP 64E NSTATIONSERVER!A5569B20ABE511CE SAP 640 WTR05240 SAP 640 NTDOMC SAP 4 MICKS_SERVER SAP 26B MICKS_DIR______________________ SAP 278 MICKS_DIR______________________ 8 entries used out of 32 IPX>
Figure 141. 2210 IPX Service Information
Hops 2 2 2 2 2 2 2 2
Age 0:15 0:15 0:15 0:15 0:15 0:15 0:15 0:15
Net / Host /Sock 9/0001CBA2470E/4004 9/0001CB32C00A/4004 9/400052005210/4008 9/400052005240/E885 9/08005A0D1E96/E885 305C27F6/000000000001/0451 305C27F6/000000000001/0005 305C27F6/000000000001/4006
171
172
Chapter 10. Multiprotocol Connectivity Using Two Routers

In this scenario we build a multiprotocol network using two routers (an IBM 2210 at the remote site and an IBM 2216 at the central site). We use data link switching (DLSw) between the routers for the transport of SNA/APPN data and NetBIOS data between the two sites. The objectives of this scenario are as follows:
To interconnect a remote LAN with a central site LAN for the transport of SNA/APPN, TCP/IP, IPX and NetBIOS. To configure DLSW for the transport of SNA/APPN and NetBIOS. To interconnect a remote IBM 5494 to a central site AS/400. To connect an IBM 2216 to an AS/400 using a LAN link. To connect an IBM 2210 to an IBM 5494 using a WAN SDLC link.

APPN network to support SNA connections TCP/IP network IPX network NetBIOS network
Figure 142. Multiprotocol Connectivity Using Two Routers
173
Routers IBM 2210 Model 14T, with MRS V2R2 and 32 MB of memory. IBM 2216, Model 400, with MAS V2R2.
WAN link between the IBM 2210 and IBM 2216 The speed of the connection is 64 Kbps. We used a modem eliminator with V.35 interfaces.
LAN multi-access units IBM 8228s to build the token-ring LAN segments.
174

In our multiprotocol router network we defined DLSW to support the SNA/APPN traffic between the remote 5494/LAN and the central AS/400. Figure 143 shows the APPN network including the network ID and CP names.
Figure 143. Multiprotocol Connectivity Using Two Routers. APPN Network.
10.2.1 AS/400 APPN Definitions

In this section we show the AS/400 APPN network definitions. For this scenario we created a token-ring line description. The AS/400 APPN node type, Network ID and CP name are defined in the system network attributes. To display the network attributes for RALYAS4C, use the command DSPNETA.
175
Figure 144. AS/400 Network Attributes Screen 1
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
: : : : : : : : : : : :
RALYAS4C
*ANY More...
From Figure 144 take note of the local network ID and local control point name. We disabled the HPR tower function on RALYAS4C. The parameter for this is on the last screen of the network attributes as shown in Figure 145.
Display Network Attributes System: Maximum hop count . . . . . . . . DDM request access . . . . . . . . Client request access . . . . . . Default ISDN network type . . . . Default ISDN connection list . . . Allow AnyNet support . . . . . . . Network server domain . . . . . . Allow APPN virtual support . . . . Allow HPR transport tower support Virtual controller autocreate APPC HPR path switch timers: Network priority . . . . . . . . High priority . . . . . . . . . Medium priority . . . . . . . . Low priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . device limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : : : : : 16 *OBJAUT *OBJAUT QDCCNNLANY *YES S100CBDM *NO *NO 100 1 2 4 8 Bottom Press Enter to continue. F3=Exit F12=Cancel RALYAS4C
We used the following command to disable HPR:
CHGNETA ALWHPRTWR(*NO)
176
HPR over DLSw If we leave Allow HPR tower transport to *YES, the autocreated APPC controller will not work, as this, by default, will have HPR(*YES) and HPR is not by default supported by data link switching. If you want to use HPR transport tower support for other links (and hence want to leave ALWHPRTWR(*YES) in the network attributes) then you have to manually create the APPC controller for the DLSw node setting HPR(*NO) in this APPC controller description. The command to do this for this scenario would be:
CRTCTLAPPC CTLD(ADJ_NODE) LINKTYPE(*LAN) SWTLINLST(TOKENRING) RMTCPNAME(CP_NAME) ADPTADR(............) NODETYPE(*NETNODE) HPR(*NO) HPRPTHSWT(*NO) TEXT( APPC Controller for 2216A )
If you want to use HPR over DLSw, then you must define the 2210 and/or 2216 for pseudo DLSw in the APPN configuration of the routers.
Token-Ring Line Description: For token-ring, the physical connection between an AS/400 and a network is defined using a line description . The token-ring adapter that we used in this scenario was associated with a File Server IO Processor (FSIOP). We therefore first created a network server description and then the actual line description.
CRTNWSD NWSD(FSIOP) RSRCNAME(CC04) TYPE(*BASE) STRNTB(*NO) TEXT( File Server IOP )

The important parameters for the network server description are: Network server description (NWSD) The unique name for this network server description. Resource name (RSRCNAME) Use the Work with Hardware Resource (WRKHDWSC) command with *CMN to find the correct resource name for the FSIOP. Network server type (TYPE) We used the FSIOP only as a LAN adapter. Start NetBIOS (STRNTB) We didn t use NetBIOS support.
CRTLINTRN LIND(TOKENRING) RSRCNAME(*NWSD) NWS(FSIOP 1) LINESPEED(16M) MAXFRAME(1994) ADPTADR(400000000000) TEXT( Token Ring Line on FSIOP ) AUTOCRTCTL(*YES)
177
The important parameters in the token-ring line description are: Line description (LIND) The unique name for this line description. Resource name (RSRCNAME) In this scenario we are using an FSIOP to connect to the network and therefore specify *NWSD as the resource name. Network server description (NWS) Specifies the network server to which this line is attached and the port to use. Line speed (LINESPEED) Specifies the line speed in bits per second (bps). Local adapter address (ADPTADR) Specifies the local system s token-ring adapter address Note: The APPC controller, APPC device, remote workstation controller and the remote workstation device descriptions are created automatically for a token-ring connection when the link between the client(s) and AS/400 becomes active provided that the QAUTOCFG and QAUTORMT system values are set to 1 (on) and the AUTOCRTCTL parameter in the token-ring line description is set to *YES.

We defined the IBM 5494 Remote Workstation Controller to communicate with AS/400 RALYAS4C. What about a 5394 If you are using the 5394 with 8Q0775 microcode diskette the configuration parameters and screens are the same as for the 5494.
0/ 1/ 2/ 3/
0 1 2 3 4 5 6 ---------------------------------------------------------00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AA 0 1- 00 - -
2- 10
3-
DD0 1 1 0 0 0 0
0 8060 P- -
178
111519-
H1:1H1:5-
H2:1H2:5-
H3:1H3:5-
H4:1H4:5-
Table 17 (Page 1 of 2). IBM 5494 Configuration Parameters Field /Subfield AA 1 2 3/1 3/2 3/3 3/4 3/5 3/6 3/7 8 P 11 12 13 14 15 16 17 18 19 Field Description Communication Mode Keyboard Code Station Address Line Type Line Facility Connection Type Data Encoding Connection Method Send Leading Pad Local Loopback Support V.25 bis Parameters Configuration Printer Network ID of 5494 LU Name of 5494 CP Name of 5494 Mode Name 5494 MAC Address Retry Parameters 5494 Serial Number 5494 ID Number 5494 ID Number 010 06 USIBMRA RAL5494 RAL5494 QRMTWSC Same as AS/400 Value Selected 0 00 10 0 1 1 0 0 0 0 060 Leased Line Full-duplex Point-to-point NRZI Value Description SDLC US English
DTR 1 No 1 No 1
179
Table 17 (Page 2 of 2). IBM 5494 Configuration Parameters Field /Subfield 20 21 22 23 H1:1 H1:2 H1:3 H1:4 H1:5 H1:7 H1:8 H1:9 Note: Field Description Primary AS/400 System Concurrent Host Attachment Concurrent Host Attachment Printer Timeout Synchronize 5494 Date and Time with Primary AS/400 AS/400 LU Name AS/400 Network ID 5494 Network ID Mode Name AS/400 MAC Address Token-Ring SAP TR Max Out TR Max In 04 2 1 RALYAS4C USIBMRA USIBMRA QRMTWSC Value Selected Value Description
1 1 1
10.2.3 Client Access Setup for SNA

In this section we show the Thinkpad set up for Personal Communications and Client Access V3R1M3. The objective is to reach the AS/400 for 5250 terminal emulation, to be able to use Client Access AS/400 Operations Navigator and to be able to use Windows Network Neighborhood to get access to the AS/400 Integrated File System (IFS). Personal Communications Setup: Follow these steps to set up the 5250 connection to the AS/400. 1. Open Start or Configure Session from the Personal Communication folder.
180
181
182
7. Enter the NetID and Partner LU name of the AS/400. This is the local control point name and the local network name of the AS/400 (see Figure 144 on page 176). 8. Press Next .
183
9. Enter the Destination address (token-ring). This is the token-ring address of RALYAS4C, in this case 400000000000 (see Token-Ring Line Description on page 177). 10. Press Next .
184
11. Press Finish and you will be asked to save this configuration. Client Access for Windows 95/NT V3R1M3 Setup: We will now set up Client Access for the AS/400 Operations Navigator. 1. From the Client Access folder in Windows 95/NT, start AS/400 Connections .
185
186
7. Enter the default user ID. 8. Press Next .
187
12. This completes the Thinkpad setup.
188

In our multiprotocol router network we defined TCP/IP to support TCP/IP traffic between the remote IP client and a central IP host. Figure 161 shows the TCP/IP network including the network addresses.
Figure 161. Multiprotocol Connectivity Using Two Routers. TCP/IP Network.
10.3.1 AS/400 TCP/IP Definitions

In this section we show the AS/400 TCP/IP network definitions. For this scenario the AS/400 is not in the route between the IP client and host. Therefore, if there is no requirement to use AS/400 TCP/IP, this section can be skipped. We show the TCP/IP definitions required to establish a TCP/IP connection between the Thinkpad and the AS/400 as an alternative to the SNA definitions created in 10.2.3, Client Access Setup for SNA on page 180. For this scenario we created:

TCP/IP interface TCP/IP route Token-ring line
The token-ring line description to be used was created in Token-Ring Line Description on page 177. This is a shared resource.
189
TCP/IP Interface Definition: To define the token-ring TCP/IP interface on RALYAS4C, we used the following command:
ADDTCPIFC INTNETADR( 1 0 . 1 . 1 . 2 ) LIND(TOKENRING) SUBNETMASK(255.255.255.0)

TCP/IP Route Definitions: In this scenario we used RouteD to maintain the AS/400 route table. With RouteD the AS/400 will learn the routes available from the 2216 router. We started RouteD with the following command:
STRTCPSVR SERVER(*ROUTED)
We used RouteD with the default parameters. Had we not used RouteD, we could have instead defined a default route to the 2216 router with the following command:
ADDTCPRTE RTEDEST( *DEFAULT ) SUBNETMASK( *none ) NEXTHOP( 1 0 . 1 . 1 . 1 )
10.3.2 IP Client Setup for TCP/IP

The Thinkpad Windows 95 TCP/IP was configured as follows: IP Address Subnet Mask Default Gateway 10.1.3.47 255.255.255.0 10.1.3.1 This points to the 2210 token-ring interface.

The IP host TCP/IP was configured as follows: IP Address Subnet Mask Route to 10.1.3.0 10.1.1.121 255.255.255.0 10.1.1.1 This points to the 2216 token-ring interface.
190
10.3.4 Client Access Setup for TCP/IP

The Thinkpad Windows 95 TCP/IP was configured as follows: IP Address Subnet Mask Default Gateway 10.1.3.48 255.255.255.0 10.1.3.1 This points to the 2210 token-ring interface. Personal Communications Setup: Follow these steps to set up the 5250 connection to the AS/400. 1. Open Start or Configure Session from the Personal Communications folder.
2. Select Telnet5250 for the Attachment and AS/400 for the host. 3. Press Configure .
191
Figure 164. Personal Communications. Telnet 5250.
5. Enter the AS/400 s Host Name or IP Address (see TCP/IP Interface Definition on page 190) and press OK .
192
10.4 The IPX Network

In our multiprotocol router network we defined IPX to support IPX traffic between the remote Novell client and a central Novell host. Figure 165 shows the IPX network including the network addresses.
Figure 165. Multiprotocol Connectivity Using Two Routers. IPX Network.
10.4.1 AS/400 IPX Definitions

In this section we show the AS/400 IPX network definitions. For this scenario the AS/400 is not in the route between the IPX client and host. Therefore, if there is no requirement to use AS/400 IPX, this section can be skipped. For this scenario we created:

IPX description IPX circuit Token-ring line
IPX Description: The IPX description is a required object and defines global (system wide) IPX configuration values. To define the IPX description on RALYAS4C, we used the following command:
193

ADDIPXCCT CCTNAME(TOKENRING) LIND(TOKENRING) IPXNETNBR(9)

The important parameters in an IPX circuit are: Circuit name (CCTNAME) We used the line description name for the circuit name. Line description (LIND) This is the line description associated with the circuit. IPX network number (IPXNETNBR) This parameter defines the external network number for this LAN/WAN connection. Consult your network administrator to determine the value to be used. Attention If there are devices on the network that are broadcasting the wrong network number, the IPX circuit won t start. You can check the Novell server system console for messages relating to this.
Since we have configured the circuits to allow NLSP and SAP to flow (the default settings), we do not have to configure IPX circuit routes or IPX circuit services. What about the controller and devices descriptions for IPX? The controller and device descriptions will be created by the system when the relevant circuit is started.
194
195
10.5 The NetBIOS Network

In our multiprotocol router network we defined NetBIOS to support NetBIOS traffic between the remote NT client and a central NT server. Figure 166 shows the IPX network including the network addresses.
Figure 166. Multiprotocol Connectivity Using Two Routers. NetBIOS Network.
We did not use the AS/400 NetBIOS support in this scenario and hence do not show any AS/400 definitions for this protocol.
196
10.6 Router Definitions

In this section we show the IBM 2216 and 2210 router configurations that were used in this scenario.
10.6.1 IBM 2216 Configuration

In this section we show the IBM 2216 configuration using the MAS configuration program. Wherever possible we accepted the defaults. We therefore only show parameters where they had to be entered or changed.
10.6.2
Starting the 2216 Configuration

We must first initialize the configuration program by selecting the 2216 hardware slots and adapters we are to use in this configuration. After starting the configuration program, we select Slots from the Adapters folder.
Figure 167. Selecting the 2216 Hardware Configuration
We selected:

2 Port TR from the pull-down menu for Slot 1. 6 Port V.35/V.36 from the pull-down menu for Slot 4. Note
The adapter locations may be different for your 2216.
197


A token-ring interface A PPP serial interface to the IBM 2210
Configuring the Token-Ring Interface 1. From the Adapters folder select Interfaces . 2. Select Configure against the token-ring interface 0.
We selected:

Cable type STP Set the MAC address to 40002216000A
198
Configuring the Serial PPP Interface 2: We used serial interface 2 to connect to the 2210. Select Configure against serial interface 2.
Figure 169. Configuring the 2216 Serial Interface to the 2210
From General we selected Encoding NRZI .
199

The token-ring interface The PPP interface to the 2210
We also configured an internal IP address. Configuring the Internal IP Address Select General from the IP folder.
Figure 170. Configuring the 2216 Internal IP Address
We entered an Internal address of 10.1.1.1. Note The internal IP address is used for data link switching. This IP address will later be defined as a DLSw TCP partner on the 2210. By convention, we normally use the LAN interface IP address as the internal IP address.
200
Configuring the Token-Ring Interface IP Address 1. Select Interfaces from the IP folder. 2. Select IP Addresses against token-ring interface 0.
We entered:

201
Configuring the PPP Interface IP Address Select IP Addresses against PPP interface 2.
Figure 172. PPP Interface IP Address 2216 Configuration
We entered:

202
Configuring RIP Select General from the RIP folder.
Figure 173. Enabling IP RIP o n the 2216
We selected Enabled.
203


We selected:

Enable IPX Entered a Host number of 00000002216A
204
Configuring IPX on the Token-Ring Interface 1. Select Interfaces from the IPX folder. 2. Check Enabled against the token-ring interface 0. 3. Select Configure against token-ring interface 0.
205
Configuring IPX on the PPP Interface 1. Check Enabled against the PPP interface 2. 2. Select Configure against PPP interface 2.
Figure 176. Configuring IPX o n the 2210 PPP Interface
We entered an IPX network number of BBB . IPX network number The IPX network number used must be unique to all other network numbers (internal and external) in this IPX internetwork. Contact the network administrator for the network number to use. For our scenario, this network number must match the 2210 s PPP interface network number.
206
10.6.2.4 Data Link Switching Configuration

Select General from the DLSw folder.
Figure 177. 2216 General DLSw Configuration
We selected:

Enable DLSw . An SRB segment number of FAB . SRB segment number
The SRB segment number must be the same for all routers participating in this data link switching network.
207
Configuring the DLSw TCP Connections Select TCP Connections from the DLSw folder.
Figure 178. Configuring the 2216 DLSw TCP Connections
We selected:
A DLSw neighbor IP address of 10.1.3.1. This is the internal IP address of the 2210.
Connectivity setup type of active . Enable keepalive . Pressed Add . Connectivity setup type
We chose to select active for connectivity setup because we could then check that the DLSw TCP connection was established prior to testing the SNA connectivity.
208
Configuring the DLSw Interfaces 1. Select Interfaces from the DLSw folder. 2. Select Configure against token-ring interface 0.
Figure 179. Configuring the 2216 DLSw Token-Ring Interface
We selected:

SAP type SNA . SAP type NetBIOS . Pressed Add after entering each SAP type.
209
Configuring Bridging: Data link switching uses bridging (transparent for Ethernet or SRB for token-ring) to bridge the SNA and NetBIOS frames to and from the local LAN. Select General from the Bridging folder.
Figure 180. Configuring General Bridging o n the 2216

Enable bridging . Enable DLSw .
210
Select SRB to enter the source route bridge parameters.
Figure 181. Configuring SRB Bridging o n the 2216
We left the parameters at the defaults. Note The Internal virtual segment number and Bridge number are set to 1 by default. If these conflict with the real segment number or bridge number of the LAN-associated interface, change the relevant value to a unique value.
211
Configuring the Bridging Interfaces 1. Select Interfaces from the Bridging folder. 2. Check Enable against the token-ring interface 0. 3. Select Configure against the token-ring interface 0.
Figure 182. Configuring Bridging o n the 2216 Token-Ring Interface
We selected:

Interface supports SRB . A Segment number of 002. The segment number used should match the segment number associated with the token-ring LAN to which the 2216 is attached.
212
10.6.2.5 Configuring NetBIOS

Select General from the NetBIOS folder to enable NetBIOS.
Figure 183. Configuring NetBIOS o n the 2216
We selected NetBIOS support . Note Although the NetBIOS folder is before the Bridging folder, NetBIOS cannot be enabled before bridging is enabled.
213

Select Configure from the Navigation Window to save the configuration and create a file to be loaded on to the router.
We selected:

Save configuration as... A Configuration name of 2216A in the config.cdb database. OK . Configure once more. Create router configuration... . A configuration file name of 2216A.CFG .
We then copied the file to a diskette and used the Xmodem file transfer protocol to install the configuration on the IBM 2216 via the service port.
214


215


A token-ring interface A frame relay interface to the AS/400 An SDLC interface to the IBM 5494
We selected:

216

Encoding NRZI Cable type V.35 DTE Entered a Clock speed of 64000
217
Configuring Serial Interface 3: We used serial interface 3 to connect to the IBM 5494. 1. Use the scroll-down bar then select SDLC from the drop-down list against interface 3. 2. Select Configure against serial interface 3.

218

We also added an internal IP address. Configuring the Internal IP Address Select General from the IP folder.
We entered an Internal address of 10.1.3.1. Note The internal IP address is used for data link switching. This IP address was defined as a DLSw TCP partner on the 2216. By convention, we normally use the LAN interface IP address as the internal IP address.
219
We entered:

220
Figure 191. IP Configuration for the 2210 PPP Interface
We entered:

221
222


We selected:

223
224
Configuring IPX on the PPP Interface 1. Check Enabled against the PPP interface 1. 2. Select Configure against the PPP interface 1.
We entered an IPX network number of BBB . IPX network number The IPX network number used must be unique to all other network numbers (internal and external) in this IPX internetwork. Contact the network administrator for the network number to use. For our scenario, this network number must match the 2216 s PPP interface network number.
225
10.7.1.5 Data Link Switching Configuration

Select General from the DLSw folder.
Figure 196. 2210 General DLSw Configuration
We selected:

Enable DLSw . An SRB segment number of FAB . SRB segment number
The SRB segment number must be the same for all routers participating in this data link switching network.
226
Configuring the DLSw TCP Connections Select TCP Connections from the DLSw folder.
Figure 197. Configuring the 2210 DLSw TCP Connections
We selected:

Connectivity setup type of active . Entered a DLSw neighbor IP address of 10.1.1.1. This is the internal IP address of the 2216.
Enable keepalive . Pressed Add . Note
We chose to select active for connectivity setup because we could then check that the DLSw TCP connection was established prior to testing the SNA connectivity.
227
Configuring the DLSw Interfaces 1. Select Interfaces from the DLSw folder. 2. Select Configure against token-ring interface 0.
Figure 198. Configuring the 2210 DLSw Token-Ring Interface
We selected:

SAP type SNA . SAP type NetBIOS . Pressed Add after entering each SAP type.
228
1. Use the Scroll down bar to display the SDLC interface 3. 2. Select Configure against SDLC interface 3.
Figure 199. Configuring the 2210 DLSw SDLC Interface
We entered:
A Source MAC address of 40005494000A. This is a pseudo MAC address for the 5494.
A Destination MAC address of 400000000000. This is the AS/400 s MAC address (see Token-Ring Line Description on page 177).
A Link address of 10. This is the 5494 s station address.
A Destination SAP of 4. Source MAC address
The source MAC address is a pseudo MAC address necessary for DLSw to convert the SDLC frames to LLC (LAN) frames.
229
Configuring Bridging: Data link switching uses bridging (transparent for Ethernet or SRB for token-ring) to bridge the SNA and NetBIOS frames to and from the local LAN. Select General from the Bridging folder.
Figure 200. Configuring General Bridging o n the 2210

Enable bridging . Enable DLSw .
230
Select SRB to enter the source route bridge parameters.
Figure 201. Configuring SRB Bridging o n the 2210
We entered a Bridge number of 2. Note The Internal virtual segment number and Bridge number used must be unique on the LAN to which the 2210 is attaching. If these numbers conflict with the real segment number or a bridge number, change the relevant value to a unique value.
231
Configuring the Bridging Interfaces 1. Select Interfaces from the Bridging folder. 2. Check Enable against the token-ring interface 0. 3. Select Configure against the token-ring interface 0.
Figure 202. Configuring Bridging o n the 2210 Token-Ring Interface
We selected:

Interface supports SRB . A Segment number of 022. The segment number used should match the segment number associated with the token-ring LAN to which the 2210 is attached.
232
10.7.1.6 Configuring NetBIOS

Select General from the NetBIOS folder to enable NetBIOS.
Figure 203. Configuring NetBIOS o n the 2210
We selected NetBIOS support . Note Although the NetBIOS folder is before the Bridging folder, NetBIOS cannot be enabled before bridging is enabled.
233

We selected:

Save configuration as... A configuration name of 2210A in the config.cdb database. OK . Configure once more. Create router configuration... A configuration file name of 2210A.CFG .
234

Before we can start the APPN, IP and IPX protocols on the AS/400, we have to vary on (activate) the network server and the token-ring line descriptions. To vary on the network server on RALYAS4C, we used the following command:
VRYCFG CFGOBJ(FSIOP) CFGTYPE(*NWS) STATUS(*ON)

The above command will also activate (vary on) the associated line descriptions. Should it be necessary to vary on the line description separately, use the command:
VRYCFG CFGOBJ(TOKENRING) CFGTYPE(*LIN) STATUS(*ON)

Now we can start an SNA 5250 terminal session on the Thinkpad to the AS/400 RALYAS4C.
Starting the Client Access connection will start the AS400 Operations Navigator.
235
We can now use the Client Access connection to reach the AS/400 IFS (Integrated File System) using the native Windows 95/NT Network Neighborhood.
236
The APPN controllers, APPN devices and the 5494 remote workstation controller and devices are autoconfigured and varied on by the AS/400. We can see the status of the AS/400 network server interface and associated configuration objects using the command:
WRKCFGSTS CFGTYPE(*NWS) CFGD(FSIOP)
RALYAS4C 14:13:11
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FSIOP TOKENRING RAL5494A RAL5494A QRMTWSC QRMTWSC THINKPAD THINKPAD QPCSUPP Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE/TARGET ACTIVE/SOURCE ACTIVE ACTIVE ACTIVE/TARGET -------------Job--------------
RAL5494A00 RAL5494A00
QUSER QUSER
070276 070276
QPASVRP
QSYS
070355
F23=More options
F24=More keys
Figure 208. Work with Configuration Status. APPN Configuration.
In Figure 208 you can see the following APPC controllers that were created by the AS/400: RAL5494A THINKPAD This is the APPN session to the 5494. This is the APPN session to the Thinkpad.
The remote workstation controller and device were also autoconfigured by the AS/400. We can see the status of these by entering the command:
WRKCFGSTS CFGTYPE(*CTL) CFGD(RAL54RMT*)
237
RALYAS4C 14:19:58
F23=More options
F24=More keys
Figure 209. Work with Configuration Status. Remote workstation controller configuration.
In Figure 209 you can see the remote workstation controller and remote workstation device descriptions that were autoconfigured by the AS/400 using the following naming convention. Autocreated configuration object naming The autocreated remote workstation controller and remote workstation device descriptions will have the following naming convention:
The following screens were captured at the 2210 router. In Figure 210, the list tcp sessions command displays the 2210 data link switching sessions.
+p dlsw Data Link Switching Console DLSw>list tcp sessions Group/Mcast@ IP Address Conn State CST Version ActSes SesCreates --------------- --------------- -------------- --- -------- ------ ---------1 10.1.1.1 ESTABLISHED a AIW V2R0 1 3
Figure 210. 2210 Data Link Switching Session Information
238
In Figure 211, the list llc2 sessions all command displays the 2210 data link switching LLC2 sessions.
DLSw>list llc2 sessions all SAP Int. Remote Addr 1. 04 0 400052005280
Local Address 400000000000
State CONTACTED
RIF 06A0 0222 FAB
Figure 211. 2210 Data Link Switching LLC2 Session Information
In Figure 212, the list sdlc sessions command displays the 2210 data link switching SDLC sessions.
DLSw>list sdlc sessions Net Address Source SAP/MAC 1. 3 10 04 40005494000A DLSw>
Dest SAP/MAC 04 400000000000
PU 2
OutQ 0
State CONTACTED
Figure 212. 2210 Data Link Switching SDLC Session Information

We did configure TCP/IP on the AS/400 and followed these steps to verify the configuration. To start the token-ring TCP/IP interface on RALYAS4C, we used the following command:
Interface not started You will receive this message if the TCP/IP support is not started on the AS/400. You start the TCP/IP on the system with the STRTCP command.
Starting a TCP/IP interface creates a *NET controller and a *NET device description under the relevant line description. We used the WRKCFGSTS CFGTYPE(*NWS) CFGD(FSIOP) command on RALYAS4C to verify this.
239
RALYAS4C 14:13:11
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FSIOP TOKENRING RAL5494A RAL5494A QRMTWSC QRMTWSC THINKPAD THINKPAD QPCSUPP TOKENNET TOKENTCP Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE/TARGET ACTIVE/SOURCE ACTIVE ACTIVE ACTIVE/TARGET ACTIVE ACTIVE -------------Job--------------
RAL5494A00 RAL5494A00
QUSER QUSER
070276 070276
QPASVRP QTCPIP
QSYS QTCP
070355 069747
F23=More options
F24=More keys
Figure 213. Work with Configuration Status. TCP/IP Configuration.
We can check the status of the TCP/IP interfaces with the command NETSTAT
*IFC.
Work with TCP/IP Interface Status System: Type options, press Enter. 5=Display details 8=Display associated routes 9=Start 10=End 12=Work with configuration status 14=Display multicast groups Internet Address 10.1.1.2 127.0.0.1 Network Address 10.1.1.0 127.0.0.0 Line Description TOKENRING *LOOPBACK Interface Status Active Active RALYAS4C
Opt
Bottom F12=Cancel
Figure 214. Work with TCP/IP Interface Status
240
We can use the command NETSTAT *RTE to see the TCP/IP route information.
Display TCP/IP Route Information System: Type options, press Enter. 5=Display details Route Destination 10.1.1.0 10.1.3.0 10.1.2.0 127.0.0.0 224.0.0.0 224.0.0.0 Subnet Mask 255.255.255.0 255.255.255.0 255.255.255.0 255.0.0.0 240.0.0.0 240.0.0.0 Next Hop *DIRECT 10.1.1.1 10.1.1.1 *DIRECT *DIRECT *DIRECT Route Available *YES *YES 1 *YES 1 *YES *YES *YES RALYAS4C
Opt
Bottom F3=Exit F5=Refresh F11=Display route type F6=Print list F12=Cancel F9=Command line F13=Sort by column F24=More keys
Figure 215. Display TCP/IP Route Information 1/2
If we press F11 we can display the route types.
Display TCP/IP Route Information System: Type options, press Enter. 5=Display details Route Destination 10.1.1.0 10.1.3.0 10.1.2.0 127.0.0.0 224.0.0.0 224.0.0.0 Type of Service *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL Route MTU 1989 1989 1989 576 1989 16388 Route Type *DIRECT *SUBNET *SUBNET *DIRECT *DIRECT *DIRECT Route Source *CFG *RIP 1 *RIP 1 *CFG *CFG *CFG RALYAS4C
Opt
F3=Exit F5=Refresh F6=Print list F12=Cancel F13=Sort by column
F9=Command line F17=Top
F11=Display next hop F18=Bottom
Figure 216. Display TCP/IP Route Information 2/2
These networks
1 have been learned from the 2216 via RIP.
241
Now we can start a TCP/IP 5250 terminal session on the Thinkpad to the AS/400 RALYAS4C.
Figure 217. Personal Communications. Telnet 5250 Connection to Host.
The following screen was captured at the 2210 router. In Figure 218, the dump command displays the 2210 TCP/IP route table.
*t 5 CGW Operator Console +p ip IP>dump Type Dest net RIP Sbnt RIP Dir* Dir* 9.0.0.0 10.0.0.0 10.1.1.0 10.1.2.0 10.1.3.0
Mask FF000000 FF000000 FFFFFF00 FFFFFF00 FFFFFF00
Cost 3 1 2 1 1
Age 30 1995 30 2034 7852
Next hop(s) 10.1.2.1 None 10.1.2.1 PPP/0 TKR/0
Routing table size: 768 nets (52224 bytes), 5 nets known 0 nets hidden, 0 nets deleted, 1 nets inactive 0 routes used internally, 762 routes free IP>
Figure 218. 2210 TCP/IP Route Information
242

We did configure IPX on the AS/400 and followed these steps to verify the configuration. First we must start IPX, on RALYAS4C we used the following command to do this:
The above command will also start the token-ring IPX circuit. Should it be necessary to start the circuit separately, use the following command to start the token-ring IPX circuit on RALYAS4C:
STRIPXCCT CCTNAME(TOKENRING)
Starting an IPX circuit creates a *NET controller and a *NET device description under the relevant line description. For the token-ring interface on RALYAS4C we used the WRKCFGSTS CFGTYPE(*NWS) CFGD(FSIOP) command to verify this.
RALYAS4C 14:52:06
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FSIOP TOKENRING RAL5494A RAL5494A QRMTWSC QRMTWSC THINKPAD THINKPAD QPCSUPP TOKENNET TOKENTCP TOKENIPX Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE/TARGET ACTIVE/SOURCE ACTIVE ACTIVE ACTIVE/TARGET ACTIVE ACTIVE ACTIVE -------------Job--------------
RAL5494A00 RAL5494A00
QUSER QUSER
070276 070276
QPASVRP QTCPIP QIPX
QSYS QTCP QSYS
070355 069747 070212
F23=More options
F24=More keys
Figure 219. Work with Configuration Status. IPX Configuration.
243
Work with IPX Circuits System: Type options, press Enter. 1=Add 2=Change 4=Remove 8=Display associated routes Circuit Name TOKENRING 5=Display 9=Start Line Description TOKENRING RALYAS4C
7=Display associated services 10=End Line Type *TRLAN Circuit Status Active
Opt
F3=Exit
F5=Refresh
F6=Print list
F12=Cancel
F17=Top
F18=Bottom
Figure 220. Work with IPX Circuits
Type options, press Enter. 5=Display details Service name MICKS_SERVER MICKS_DIR________> MICKS_DIR________> Service Type *FILESVR 026B 0278 Remote Network 305C27F6 305C27F6 305C27F6 Hops to Service 1 1 1 Service Source *SAP *SAP *SAP
Opt
F3=Exit
F5=Refresh
F6=Print list
F12=Cancel
F17=Top
F18=Bottom
Figure 221. Work with IPX Services Information
244
A:\NWCLIENT>STARTNET NetWare Link Support Layer v2.14 (941011) (C) Copyright 1990-1994 Novell, Inc. All Rights Reserved. The configuration file used was A:\NWCLIENT\NET.CFG . Max Boards 4, Max Stacks 4 IBM Token-Ring MLID v1.29 (941007) (C) Copyright 1993 - 1994 IBM Corporation.
TOKENCS-DOS-200: Inserting into the ring. Please Wait. Int 2, Port A20, Mem D0000, Mem D8000, Node Address 8005AE475B9 M Max Frame 4210 bytes, Line Speed 16 Mbps Board 1, Frame TOKEN-RING, MSB Mode NetWare IPX/SPX Protocol v3.01 (941031) (C) Copyright 1990-1994 Novell, Inc. All Rights Reserved. IPX RETRY COUNT 50 Bound to logical board 1 (TOKENCS) : Protocol ID E0 NetWare Source Routing Driver v2.21 (940315) (C) Copyright 1993 Novell Inc. All Rights Reserved. ROUTE-DOS-200: Current ROUTE.com parameters for Board #1 are: DEFault Node (Unknown) Addresses are sent SINGLE ROUTE Broadcast. Broadcast (FFFF FFFF FFFF) Addresses are sent SINGLE ROUTE Broadcast. Multicast (C000 xxxx xxxx) Addresses are sent SINGLE ROUTE Broadcast. Maximum HOPS = 7 Bridges; NODES = 16; Aging TIME = 10 Seconds. This Ring Only (TRO) Count = 0; Extra Transmit (XTX) Count = 2. VLM.EXE - NetWare virtual loadable module manager (C) Copyright 1994 Novell, Inc. All Rights Reserved. Patent pending. v1.20 (941108)
NetBIOS was verified by the establishment of a connection between the NT workstation and the NT server using NetBIOS.
245
246
Chapter 11. Multiprotocol Connectivity with Backup

In this scenario we build a multiprotocol network that allows for link failure without loss of the communications session. The network is comprised of two remote sites, the link to each of these sites backs up the link to the other. We use HPR for the SNA/APPN sessions. Frame relay is used to provide high speed WAN connections between the remote sites and the central site. The objectives of this scenario are as follows:
To interconnect remote LANs with a central site LAN for the transport of SNA/APPN, TCP/IP and IPX. To interconnect remote IBM 5494s and a remote AS/400 to a central site AS/400. To connect an IBM 2210 to an AS/400 using frame relay WAN links. To connect IBM 5494s to IBM 2210s using WAN SDLC links. To configure native APPN/HPR, TCP/IP and IPX protocols.

APPN/HPR network to support SNA connections TCP/IP network IPX network
Figure 223. Backup Scenario Using Frame Relay Connections Copyright IBM Corp. 1996 1999
247
Routers IBM 2210 Model 14T, with MRS V2R2 and 32 MB of memory. IBM 2210 Model 24E, with MRS V2R2 and 32 MB of memory.
Frame relay WAN links between the AS/400 and the 2210s The speed of the connections is 64 Kbps. We used modem eliminators with V.35 interfaces.
A lower speed frame relay WAN link between the 2210s The speed of the connections is 19200 bps. We used a V.24 DCE cable and a V.24 DTE cable.
WAN links between the IBM 2210s and the IBM 5494s The speed of the connections is 19200 bps. We used V.24 DCE cables for the 2210s and the normal V.24 5494 cables.
LAN multi-access units/hub: IBM 8228 to build the token-ring LAN segment. IBM 8271 to build the Ethernet LAN segment.
IBM 5494 remote workstation controller. With Release 3.2 microcode. Configured for V.24 SDLC upstream and twinax devices attached. What about the IBM 5394 When connecting an IBM 5394 to a 2210 router, the 8Q0775 microcode diskette is required. This microcode allows the 5394 to participate in an APPN network as a low-entry node. To order, contact your IBM representative or IBM authorized business partner. If you would like additional information visit the IBM 5394 home page at: http://www.networking.ibm.com/539/539prod.html or the IBM Networking home page at: http://www.networking.ibm.com The diskette image for RPQ 8Q0775 is NOT available on the Web and must be ordered via an MES order.
Two AS/400 systems: One system with two frame relay adapters (feature #2666) and one LAN adapter. One system with one LAN adapter. With OS/400 V4R2.
248

In our multiprotocol router network we defined APPN/HPR to support the SNA/APPN traffic between the remote AS/400 / 5494s / LANs and the central site. We used HPR to provide session re-routing in the event of a link failure. The IBM 2210s and the central AS/400 are configured as APPN network nodes, the remote AS/400 is configured as an APPN end node and the 5494s are LEN nodes. Figure 224 shows the APPN network including the network ID and CP names.
Figure 224. Backup Scenario Using Frame Relay. APPN/HPR Network.
11.2.1 AS/400 APPN Definitions (RALYAS4C)


A token-ring line description Frame relay network interface descriptions Frame relay line descriptions
AS/400 Network Attributes: The AS/400 APPN node type, Network ID and CP name are defined in the system network attributes. To display the network attributes for RALYAS4C, use the command DSPNETA.
249
Figure 225. RALYAS4C Network Attributes Screen 1
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
: : : : : : : : : : : :
RALYAS4C
*ANY More...
From Figure 225 take note of the local network ID and local control point name. We enabled the HPR tower function on RALYAS4C. The parameter for this is on the last screen of the network attributes as shown in Figure 226.
Display Network Attributes System: Maximum hop count . . . . . . . . DDM request access . . . . . . . . Client request access . . . . . . Default ISDN network type . . . . Default ISDN connection list . . . Allow AnyNet support . . . . . . . Network server domain . . . . . . Allow APPN virtual support . . . . Allow HPR transport tower support Virtual controller autocreate APPC HPR path switch timers: Network priority . . . . . . . . High priority . . . . . . . . . Medium priority . . . . . . . . Low priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . device limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : : : : : 16 *OBJAUT *OBJAUT QDCCNNLANY *YES S100CBDM *NO *YES 100 1 2 4 8 RALYAS4C
Bottom Press Enter to continue. F3=Exit F12=Cancel
If necessary, use the following command to enable HPR:
CHGNETA ALWHPRTWR(*YES)
Token-Ring Line Description: For token-ring, the physical connection between an AS/400 and a network is defined using a line description . To define the token-ring line on RALYAS4C, we used the following command:
250
CRTLINTRN LIND(TRN2619C) RSRCNAME(CMN02) LINESPEED(16M) MAXFRAME(19940 ADPTADR(400052005019) TEXT(16 M token ring line - CMN02 ) AUTOCRTCTL(*YES)
The important parameters in the token-ring line description are: Line description (LIND) The unique name for this line description. Resource name (RSRCNAME) Use the Work with Hardware Resource command with *CMN (WRKHDWRSC *CMN) to locate the resource name for the token-ring adapter. Line speed (LINESPEED) Specifies the line speed in bits per second (bps). Local adapter address (ADPTADR) Specifies the local system s token-ring adapter address. The APPC controller, APPC device, remote workstation controller and the remote workstation device descriptions are created automatically for a token-ring connection when the link with the client(s) and AS/400 becomes active providing the QAUTOCFG and QAUTORMT system values are set to 1 (on) and the AUTOCRTCTL parameter in the token-ring line description is set to *YES. Frame Relay Network Interface Description 1: For frame relay, the frame relay interface description defines the AS/400 s physical interface to the network. To define the frame relay interface on RALYAS4C, we used the following command:
CRTNWIFR NWID(FR_RELAY_A) RSRCNAME(CMN10) NRZI(*YES) INTERFACE(*V35) LINESPEED(64000) LMIMODE(*NONE) TEXT( Frame Relay Network Interface on CMN10 )
The important parameters in the frame relay interface description are: Network interface description (NWID) The unique name for this network interface description Resource name (RSRCNAME) Use the Work with Hardware Resource command with *CMN (WRKHDWRSC *CMN) to locate the resource name for the frame relay adapter. NRZI data encoding (NRZI) Specifies whether non-return-to-zero-inverted (NRZI) data encoding is used for this connection. Physical interface (INTERFACE) Specifies the type of physical interface on the input/output adapter (IOA) port. LMI mode (LMIMODE) Specifies whether the local management interface (LMI) for this adapter is configured as terminal equipment, a frame handler or *NONE.
251
LMI We use *NONE because the AS/400 and the 2210 are connected back-to-back. We did not have a frame relay network between the two.
Frame Relay Line Description for APPN to 2210A: For frame relay, the line description allocates a protocol to a physical frame relay DLCI. To define the frame relay line on RALYAS4C that is to be used for APPN/HPR, we used the following command:
CRTLINFR LIND(FR_HPR_A) NWI(FR_RELAY_A) NWIDLCI(444) TEXT( Frame Relay Line to 2210A on DLC 444 )
DLC identifier (NWIDLCI) Specifies the network interface data link connection identifier (DLCI) to be used. This would normally be supplied by the frame relay network provider. APPC Controller Description for 2210A: The remote APPN node is defined using a controller description . For APPN we define an APPC controller description. To define the 2210 APPN connection, we used the following command:
CRTCTLAPPC CTLD(HPR2210A) LINKTYPE(*FR) SWTLINLST(FR_HPR_A) RMTCPNAME(HPR2210A) NODETYPE(*NETNODE) TEXT( APPC Controller for 2210A ) SWTDSC(*NO)
The important parameters in the APPC controller for the 2210 are: Controller description (CTLD) The unique name for the controller description. Switched line list (SWTLINLST) Specifies the names of the switched lines to which this controller can attach. Remote control point (RMTCPNAME) Specifies the remote control point name of the 2210. APPN node type (NODETYPE) The 2210 will be a NETNODE in this APPN network. Switched disconnect (SWTDSC) We set this parameter to *NO to prevent the connection from being dropped when the last device is varied off. The APPC device, remote workstation controller and remote workstation device descriptions are created automatically when the links become active providing the QAUTOCFG and QAUTORMT system values are set to 1 (on).
252
Frame Relay Network Interface Description 2: For frame relay, the frame relay interface description defines the AS/400 s physical interface to the network. To define the frame relay interface on RALYAS4C, we used the following command:
CRTNWIFR NWID(FR_RELAY_B) RSRCNAME(CMN11) NRZI(*YES) INTERFACE(*V35) LINESPEED(64000) LMIMODE(*NONE) TEXT( Frame Relay Network Interface on CMN11 )
The important parameters in the frame relay interface description are: Network interface description (NWID) The unique name for this network interface description. Resource name (RSRCNAME) Use the Work with Hardware Resource command with *CMN (WRKHDWRSC *CMN) to locate the resource name for the frame relay adapter. NRZI data encoding (NRZI) Specifies whether non-return-to-zero-inverted (NRZI) data encoding is used for your modem. Physical interface (INTERFACE) Specifies the type of physical interface on the input/output adapter (IOA) port. LMI mode (LMIMODE) Specifies whether the local management interface (LMI) for this adapter is configured as terminal equipment, a frame handler or *NONE. LMI We use *NONE because the AS/400 and the 2210 are connected back-to-back. We did not have a frame relay network between the two.
Note The environment we set up was using frame relay protocols but was not actually using a frame relay network. We had two local point-to-point connections: one to 2210A and on to 2210B. This required two feature 2666 adapters and two NWIDs (Network Interface Descriptions). In a real customer environment, where the AS/400 is connected to a real frame relay network, we would have a single 2666 adapter connecting to the network with a single NWID.
Frame Relay Line Description for APPN to 2210B: For frame relay, the line description allocates a protocol to a physical frame relay DLCI. To define the frame relay line on RALYAS4C that is to be used for APPN/HPR, we used the following command:
CRTLINFR LIND(FR_HPR_B) NWI(FR_RELAY_B) NWIDLCI(444) TEXT( Frame Relay Line to 2210B on DLC 444 )
253
DLC identifier (NWIDLCI) Specifies the network interface data link connection identifier (DLCI) to be used. This would normally be supplied by the frame relay network provider. APPC Controller Description for 2210B: The remote APPN node is defined using a controller description . For APPN we define an APPC controller description. To define the 2210 APPN connection, we used the following command:
CRTCTLAPPC CTLD(HPR2210B) LINKTYPE(*FR) SWTLINLST(FR_HPR_B) RMTCPNAME(HPR2210B) NODETYPE(*NETNODE) TEXT( APPC Controller for 2210B ) SWTDSC(*NO)
The important parameters in the APPC controller for the 2210 are: Controller description (CTLD) The unique name for the controller description. Switched line list (SWTLINLST) Specifies the names of the switched lines to which this controller can attach. Remote control point (RMTCPNAME) Specifies the remote control point name of the 2210. APPN node type (NODETYPE) The 2210 will be a NETNODE in this APPN network. Switched disconnect (SWTDSC) We set this parameter to *NO to prevent the connection from being dropped when the last device is varied off. The APPC device, remote workstation controller and remote workstation device descriptions are created automatically when the links become active providing the QAUTOCFG and QAUTORMT system values are set to 1 (on).
11.2.2 AS/400 APPN Definitions (RALYAS4A)

The AS/400 APPN node type, Network ID and CP name are defined in the system network attributes. To display the network attributes for RALYAS4A, use the command DSPNETA.
254
Figure 227. RALYAS4A Network Attributes Screen 1
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
: : : : : : : : : : : :
System: RALYAS4A USIBMRA RALYAS4A RALYAS4A BLANK *ENDNODE *NONE *NONE 200 128 *LCLNETID
RALYAS4A
*ANY More...
From Figure 227 take note of the local network ID and local control point name. We enabled the HPR tower function on RALYAS4A. This is shown in the last screen of the network attributes as shown in Figure 228.
Display Network Attributes System: Maximum hop count . . . . . . . . DDM request access . . . . . . . . Client request access . . . . . . Default ISDN network type . . . . Default ISDN connection list . . . Allow AnyNet support . . . . . . . Network server domain . . . . . . Allow APPN virtual support . . . . Allow HPR transport tower support Virtual controller autocreate APPC HPR path switch timers: Network priority . . . . . . . . High priority . . . . . . . . . Medium priority . . . . . . . . Low priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . device limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : : : : : 16 *OBJAUT *OBJAUT QDCCNNLANY *YES S100CBDM *NO *YES 100 1 2 4 8 RALYAS4A
Token-Ring Line Description: For token-ring, the physical connection between an AS/400 and a network is defined using a line description . The token-ring adapter that we used in this scenario was associated with an
255
Integrated PC Server (IPCS). We therefore first created a network server description then the actual line description.
CRTNWSD NWSD(IPCSBASE) RSRCNAME(LIN04) TYPE(*BASE) STRNTB(*NO) TEXT( File Server IOA )

The important parameters for the network server description are: Network server description (NWSD) The unique name for this network server description. Resource name (RSRCNAME) Use the Work with Hardware Resource (WRKHDWSC) command with *CMN to find the correct resource name for the FSIOP. Network server type (TYPE) We used the FSIOP only as a LAN adapter. Start NetBIOS (STRNTB) We didn t use NetBIOS support.
CRTLINTRN LIND(TOKENRING) RSRCNAME(*NWSD) NWS(IPCSBASE 1) LINESPEED(16M) MAXFRAME(1994) ADPTADR(400000000150) TEXT( Token Ring Line on IPCSBASE )
The important parameters in the token-ring line description are: Line description (LIND) The unique name for this line description. Resource name (RSRCNAME) In this scenario we are using an IPCS to connect to the network and therefore specify *NWSD for the resource name. Network server description (NWS) Specifies the network server to which this line is attached and the port to use. Line speed (LINESPEED) Specifies the line speed in bits per second (bps). Local adapter address (ADPTADR) Specifies the local system s token-ring adapter address. The APPC controller and APPC device are created automatically when the link between the 2210 and AS/400 becomes active provided that the QAUTOCFG value is set to 1 (on) and the AUTOCRTCTL parameter in the token-ring line description is set to *YES. Alternatively, we could have created the APPC controller description manually with the command:
CRTCTLAPPC CTLD(HPR2210A) LINKTYPE(*LAN) SWTLINLST(TOKENRING) RMTCPNAME(HPR2210A) ADPTADR(400022100014) NODETYPE(*NETNODE) TEXT( APPC Controller for 2210A )
256
CALL QCMD If entered as shown, the command above will overflow the number of command entry lines made available. We can get extra lines by entering the command CALL QCMD.

We defined the IBM 5494 remote workstation controllers to communicate with AS/400 RALYAS4C. What about a 5394 If you are using the 5394 with 8Q0775 microcode diskette the configuration parameters and screens are the same as for the 5494.
11.2.3.1 IBM 5494 Definitions (RAL5494A)

0 1 2 3 4 5 6 ---------------------------------------------------------00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0/ 1/ 2/ 3/
AA 0 1- 00 - -
2- 10
3-
DD0 1 1 0 0 0 0
0 8060 P- -
257
111519-
USIBMRA 12- RAL5494A 13- RAL5494A 14- QRMTWSC_ _______________ 16- 010 06 1 17- 00-00000 18________ 00001 20- 1 21- 0 22- 000 23- 0
H1:1H1:5-
H2:1H2:5-
H3:1H3:5-
H4:1H4:5-
Table 18 (Page 1 of 2). IBM 5494 Configuration Parameters Field /Subfield AA 1 2 3/1 3/2 3/3 3/4 3/5 3/6 3/7 8 P 11 12 13 14 15 16 17 18 19 20 Field Description Communication Mode Keyboard Code Station Address Line Type Line Facility Connection Type Data Encoding Connection Method Send Leading Pad Local Loopback Support V.25 bis Parameters Configuration Printer Network ID of 5494 LU Name of 5494 CP Name of 5494 Mode Name 5494 MAC Address Retry Parameters 5494 Serial Number 5494 ID Number 5494 ID Number Primary AS/400 System 010 06 USIBMRA RAL5494A RAL5494A QRMTWSC Same as AS/400 Value Selected 0 00 10 0 1 1 0 0 0 0 060 Leased Line Full-duplex Point-to-point NRZI Value Description SDLC US English
DTR 1 No 1 No 1
258
Table 18 (Page 2 of 2). IBM 5494 Configuration Parameters Field /Subfield 21 22 23 H1:1 H1:2 H1:3 H1:4 H1:5 H1:7 H1:8 H1:9 Note: Field Description Concurrent Host Attachment Concurrent Host Attachment Printer Timeout Synchronize 5494 Date and Time with Primary AS/400 AS/400 LU Name AS/400 Network ID 5494 Network ID Mode Name AS/400 MAC Address Token-Ring SAP TR Max Out TR Max In 04 2 1 RALYAS4C USIBMRA USIBMRA QRMTWSC Value Selected Value Description
1 1 1
11.2.3.2 IBM 5494 Definitions (RAL5494B)

0 1 2 3 4 5 6 ---------------------------------------------------------00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0/ 1/ 2/ 3/
AA 0 1- 00 - -
2- 20
3-
DD0 1 1 0 0 0 0
0 8060 P- -
259
111519-
USIBMRA 12- RAL5494B 13- RAL5494B 14- QRMTWSC_ _______________ 16- 010 06 1 17- 00-00000 18________ 00001 20- 1 21- 0 22- 000 23- 0
H1:1H1:5-
H2:1H2:5-
H3:1H3:5-
H4:1H4:5-
Figure 232. IBM 5494 Setup Panel, 2 of 2 - Connecting to RALYAS4C
Table 19 (Page 1 of 2). IBM 5494 Configuration Parameters Field /Subfield AA 1 2 3/1 3/2 3/3 3/4 3/5 3/6 3/7 8 P 11 12 13 14 15 16 17 18 19 Field Description Communication Mode Keyboard Code Station Address Line Type Line Facility Connection Type Data Encoding Connection Method Send Leading Pad Local Loopback Support V.25 bis Parameters Configuration Printer Network ID of 5494 LU Name of 5494 CP Name of 5494 Mode Name 5494 MAC Address Retry Parameters 5494 Serial Number 5494 ID Number 5494 ID Number 010 06 USIBMRA RAL5494B RAL5494B QRMTWSC Same as AS/400 Value Selected 0 00 20 0 1 1 0 0 0 0 060 Leased Line Full-duplex Point-to-point NRZI Value Description SDLC US English
DTR 1 No 1 No 1
260
Table 19 (Page 2 of 2). IBM 5494 Configuration Parameters Field /Subfield 20 21 22 23 H1:1 H1:2 H1:3 H1:4 H1:5 H1:7 H1:8 H1:9 Note: Field Description Primary AS/400 System Concurrent Host Attachment Concurrent Host Attachment Printer Timeout Synchronize 5494 Date and Time with Primary AS/400 AS/400 LU Name AS/400 Network ID 5494 Network ID Mode Name AS/400 MAC Address Token-Ring SAP TR Max Out TR Max In 04 2 1 RALYAS4C USIBMRA USIBMRA QRMTWSC Value Selected Value Description
1 1 1
261

In our multiprotocol router network we defined TCP/IP to support TCP/IP traffic between the remote IP clients and the central IP host. Figure 233 shows the TCP/IP network including the network addresses.
Figure 233. Backup Scenario using Frame Relay. TCP/IP Network.
11.3.1 AS/400 TCP/IP Definitions (RALYAS4C)


Frame relay line descriptions for each of the 2210 connections TCP/IP interfaces TCP/IP routes Token-ring line description and frame relay network interface
The token-ring line description and frame relay network interface to be used were created in Token-Ring Line Description on page 250 and Frame Relay Network Interface Description 1 on page 251. These are shared resources.
Frame Relay Line Description for TCP/IP to 2210A: To define the frame relay line on RALYAS4C that is to be used for TCP/IP to 2210A, we used the following command:
262
CRTLINFR LIND(FR_TCPIP_A) NWI(FR_RELAY_A) NWIDLCI(222) TEXT( Frame Relay Line for TCP/IP to 2210A DLCI 222 )
DLC identifier (NWIDLCI) Specifies the network interface data link connection identifier (DLCI) to be used. This would normally be supplied by the frame relay network provider. Frame Relay Line Description for TCP/IP to 2210B: To define the frame relay line on RALYAS4C that is to be used for TCP/IP to 2210B, we used the following command:
CRTLINFR LIND(FR_TCPIP_B) NWI(FR_RELAY_B) NWIDLCI(222) TEXT( Frame Relay Line for TCP/IP to 2210B DLCI 222 )
TCP/IP Interface Definitions: We created two TCP/IP interfaces on RALYAS4C: 9.24.104.162 10.1.2.1 10.1.6.1 This is the local LAN interface. This is the WAN frame relay interface to 2210A. This is the WAN frame relay interface to 2210B.
To define the token-ring TCP/IP interface on RALYAS4C, we used the following command:
ADDTCPIFC INTNETADR(9.24.104.162) LIND(TRN2619C) SUBNETMASK(255.255.255.0)

To define the first frame relay TCP/IP interface on RALYAS4C, we used the following command:
ADDTCPIFC INTNETADR( 1 0 . 1 . 2 . 1 ) LIND(FR_TCPIP_A) SUBNETMASK(255.255.255.0)

To define the second frame relay TCP/IP interface on RALYAS4C, we used the following command:
ADDTCPIFC INTNETADR( 1 0 . 1 . 6 . 1 ) LIND(FR_TCPIP_B) SUBNETMASK(255.255.255.0)

263
TCP/IP Route Definitions: We created the following TCP/IP routes on RALYAS4C: *DFTROUTE 10.1.3.0 This is the default route, and points to a router on the local LAN. This is the remote 2210A TCP/IP network. To allow for link failure, we have two routes to this network. The primary route is directed at 2210A s frame relay interface, and the backup route is directed at 2210B s frame relay interface. This is the remote 2210B TCP/IP network. To allow for link failure, we have two routes to this network. The primary route is directed at 2210B s frame relay interface, the backup route is directed at 2210A s frame relay interface.
10.1.4.0
To define the default TCP/IP route on RALYAS4C, we used the following command:
ADDTCPRTE RTEDEST( *DFTROUTE ) SUBNETMASK( *NONE ) NEXTHOP(9.24.104.1)

To define the TCP/IP routes on RALYAS4C to the 10.1.3 network, we used the following commands:
ADDTCPRTE RTEDEST( 1 0 . 1 . 3 . 0 ) SUBNETMASK(255.255.255.0) NEXTHOP( 1 0 . 1 . 2 . 2 ) BINDIFC( 1 0 . 1 . 2 . 1 ) MTU(*IFC) DUPRTEPTY(10) ADDTCPRTE RTEDEST( 1 0 . 1 . 3 . 0 ) SUBNETMASK(255.255.255.0) NEXTHOP( 1 0 . 1 . 6 . 2 ) BINDIFC( 1 0 . 1 . 6 . 1 ) MTU(*IFC) DUPRTEPTY(5)
To define the TCP/IP routes on RALYAS4C to the 10.1.4 network, we used the following commands:
ADDTCPRTE RTEDEST( 1 0 . 1 . 4 . 0 ) SUBNETMASK(255.255.255.0) NEXTHOP( 1 0 . 1 . 6 . 2 ) BINDIFC( 1 0 . 1 . 6 . 1 ) MTU(*IFC) DUPRTEPTY(10) ADDTCPRTE RTEDEST( 1 0 . 1 . 4 . 0 ) SUBNETMASK(255.255.255.0) NEXTHOP( 1 0 . 1 . 2 . 2 ) BINDIFC( 1 0 . 1 . 2 . 1 ) MTU(*IFC) DUPRTEPTY(5)
The important parameters for the TCP/IP routes are: Remote destination (RTEDEST) Specifies the TCP/IP address of the remote network this route applies to.
264
Subnet mask (SUBNETMASK) Specifies the remote network subnet mask. Next hop (NEXTHOP) Specifies the next hop on the route to the remote network, and the address to which the TCP/IP packets should be sent. Preferred binding interface (BINDIFC) Specifies the IP interface to bind this route to. The bind is not absolute. If no connection can be made, an alternate interface will be used. This parameter is useful when the destination can be reached using multiple IP interfaces. If the IP interface specified is active, the route will bind to it. If it is not active, an alternate and active IP interface that uses the same line description will be used. If the IP interface specified is not active, and no active alternate interfaces using the same line description can be found, then any active IP interface on the same network will be used, regardless of line description. If no active IP interfaces on the same network as the specified interface can be found, the route will be disabled. Maximum transmission unit (MTU) By specifying *IFC the maximum transmission unit size is the MTU of the interface that is associated with this route. Duplicate route priority (DUPRTEPTY) Routes with a high duplicate route priority will be tried before routes with a low priority. The valid range is 1 to 10. The default value is 5. RouteD AS/400 RouteD is not supported for frame relay connections. We could not, therefore, use this to locate the 10.1.3 or 10.1.4 networks and hence the static routes defined above.
11.3.2 AS/400 TCP/IP Definitions (RALYAS4A)


TCP/IP interface TCP/IP route Token-ring line description
To define the token-ring TCP/IP interface on RALYAS4A, we used the following command:
ADDTCPIFC INTNETADR(10.1.3.150) LIND(TOKENRING) SUBNETMASK(255.255.255.0)

In this scenario we defined a default route on RALYAS4A rather than RouteD. The reason for this was that RouteD was unable to locate a route through to the
265
9.24.104 network. The default route was to the 2210 router and was defined using the following command:
ADDTCPRTE RTEDEST( *DEFAULT ) SUBNETMASK( *none ) NEXTHOP( 1 0 . 1 . 3 . 1 )
11.3.3 ThinkpadA Setup for TCP/IP

The Thinkpad Windows 95 TCP/IP was configured as follows: IP Address Subnet Mask Default Gateway 10.1.3.47 255.255.255.0 10.1.3.1 This points to the 2210A token-ring interface.
11.3.4 ThinkpadB Setup for TCP/IP

The Thinkpad Windows 95 TCP/IP was configured as follows: IP Address Subnet Mask Default Gateway 10.1.4.47 255.255.255.0 10.1.4.1 This points to the 2210B token-ring interface.

The IP host TCP/IP was configured as follows: IP Address Subnet Mask Route to 10.1.3.0 Route to 10.1.4.0 9.24.104.121 255.255.255.0 Gateway: 9.24.104.162 Subnet mask: 255.255.255.0 Gateway: 9.24.104.162 Subnet mask: 255.255.255.0 The routes point to the token-ring interface of AS/400 RALYAS4C.
266

In our multiprotocol router network we defined IPX to support IPX traffic between the remote Novell clients and the central Novell host. Figure 234 shows the IPX network including the network addresses.
Figure 234. Backup Scenario Using Frame Relay. IPX Network.
11.4.1 AS/400 IPX Definitions (RALYAS4C)

In this section we show the AS/400 IPX network definitions. For this scenario we created:

Frame relay line descriptions IPX description IPX circuits Token-ring line and frame relay network interface
The token-ring line description and frame relay network interface to be used were created in Token-Ring Line Description on page 250 and Frame Relay Network Interface Description 1 on page 251. These are shared resources.
Frame Relay Line Description for IPX: For frame relay, the line description allocates a protocol to a physical frame relay DLCI. To define the frame relay line on RALYAS4C that is to be used for IPX to 2210A, we used the following command:
267
CRTLINFR LIND(FR_IPX_A)) NWI(FR_RELAY_A) NWIDLCI(333) TEXT( Frame Relay Line for IPX to 2210A DLCI 333 )
To define the frame relay line on RALYAS4C that is to be used for IPX to 2210B, we used the following command:
CRTLINFR LIND(FR_IPX_B) NWI(FR_RELAY_B) NWIDLCI(333) TEXT( Frame Relay Line for IPX to 2210B DLCI 333 )
DLC identifier (NWIDLCI) Specifies the network interface data link connection identifier (DLCI) to be used. This would normally be supplied by the frame relay network provider. IPX Description: The IPX description is a required object and defines global (system wide) IPX configuration values. To define the IPX description on RALYAS4C, we used the following command:

We created three IPX circuits on RALYAS4C: Token-ring This is circuit defines the logical IPX connection to the token-ring.
268
Frame relay to 2210A This circuit defines the logical IPX connection to the frame relay network connection to 2210A. Frame relay to 2210B This circuit defines the logical IPX connection to the frame relay network connection to 2210B. To define the token-ring IPX circuit on RALYAS4C, we used the following command:
ADDIPXCCT CCTNAME(TRN2619C) LIND(TRN2619C) IPXNETNBR(9)

To define the frame relay IPX circuit for 2210A on RALYAS4C, we used the following command:
ADDIPXCCT CCTNAME(FR_IPX_A) LIND(FR_IPX_A) IPXNETNBR(1012) ENBNLSP(*NO) ENBIW2(*NO)

To define the frame relay IPX circuit for 2210B on RALYAS4C, we used the following command:
ADDIPXCCT CCTNAME(FR_IPX_B) LIND(FR_IPX_B) IPXNETNBR(1016) ENBNLSP(*NO) ENBIW2(*NO)

The important parameters in the IPX circuits are: Circuit name (CCTNAME) We used the line description name for the circuit name. Line description (LIND) This is the line description associated with the circuit. IPX network number (IPXNETNBR) This parameter defines the external network number for this LAN/WAN connection. Consult your network administrator to determine the value to be used. Attention If there are devices on the network that are broadcasting the wrong network number, the IPX circuit won t start. You can check the Novell server system console for messages relating to this. Enable for NSLP(ENBNLSP) The 2210 does not support NLSP at the release level we are using. We have therefore disabled NLSP for this link. Enable for IW2 (ENBIW2) We have also disabled IPX WAN Version 2 negotiations for this link. The 2210 does not support IW2 either. Since we have configured the circuits to allow NLSP and SAP to flow (the default settings), we do not have to configure IPX circuit routes or IPX circuit services.
269
What about the controller and device descriptions for IPX? The controller and device descriptions will be created by the system when the relevant circuit is started.
11.4.2 AS/400 IPX Definitions (RALYAS4A)

In this section we show the AS/400 IPX network definitions. For this scenario RALYAS4A is not in a route between the IPX clients and the IPX host. Therefore, if there is no requirement to use IPX from this AS/400, this section can be skipped. We used the AS/400 IPX support to verify the IPX connections over the network. For this scenario we created:

IPX description IPX circuit Token-ring line
IPX Description: The IPX description is a required object and defines global (system wide) IPX configuration values. To define the IPX description on RALYAS4A, we used the following command:
CRTIPXD IPXD(RALYAS4A) IPXNETNBR(*RANDOM) IPXRTRNAME(RALYAS4A) TEXT( IPX Description for RALYAS4A )

The important parameters in an IPX description are: IPX description (IPXD) We used the system name for the IPX description name. IPX internal network number (IPXNETNBR) The IPX network number used for the AS/400 s internal IPX network must be unique to all other network numbers (internal and external) in this IPX internetwork. Contact the network administrator for the network number to use. *RANDOM will randomly generate an IPX network number. IPX Circuit: An IPX circuit must defined for each line over which IPX routing will be used. What is an IPX circuit? An IPX circuit is a logical representation of a path for IPX communication. Circuits are not physical objects. Each circuit is associated with a line description. The line description describes the physical connection from the AS/400 to the network. The circuit defines the logical path from the IPX protocol layer to the line. A line description is a shared configuration object; a previously created line description can be used for IPX also.
To define the token-ring IPX circuit on RALYAS4A, we used the following command:
270

The important parameters in the IPX circuits are: Circuit name (CCTNAME) We used the line description name for the circuit name. Line description (LIND) This is the line description associated with the circuit. IPX network number (IPXNETNBR) This parameter defines the external network number for this LAN/WAN connection. Consult your network administrator to determine the value to be used. Attention If there are devices on the network that are broadcasting the wrong network number, the IPX circuit won t start. You can check the Novell server system console for messages relating to this.
Since we have configured the circuits to allow NLSP and SAP to flow (the default settings), we do not have to configure IPX circuit routes or IPX circuit services. What about the controller and device descriptions for IPX? The controller and device descriptions will be created by the system when the relevant circuit is started.
271

In this section we show the IBM 2210 router configurations that were used in this scenario.
11.5.1 IBM 2210A Configuration

In this section we show the IBM 2210 configuration using the MRS configuration program. Wherever possible we accepted the defaults. We therefore only show where parameters had to be entered or changed.

272


A token-ring interface A frame relay interface to the AS/400 A frame relay interface to 2210B An SDLC interface to the IBM 5494
We selected:

273

274
By default the LMI box is checked. We unchecked this box as we were not using a real frame relay network.
275
We added:

Circuit Number 222 with the Circuit name IP . Circuit Number 333 with the Circuit name IPX . Circuit Number 444 with the Circuit name APPN . Pressed Add after each selection.
276
We added:

277
Configuring the Serial Frame Relay Interface 2: We used serial interface 2 to connect to 2210B. 1. Select Frame Relay from the drop-down list against interface 2. 2. Select Configure against serial interface 2.
Figure 241. Configuring the 2210 Serial Interface to 2210B

278
279
We added:

280
We added:

Protocol IP to Circuit Number 555 with an address of 10.1.5.1. Protocol IPX to Circuit Number 666 with an IPX host number of 00000002210A. Pressed Add after selection.
281

282

The token-ring interface The frame relay interface to the AS/400 The frame relay interface to 2210B
We also added a default route. Configuring the Token-Ring Interface IP Address 1. Select Interfaces from the IP folder. 2. Select IP Addresses against token-ring interface 0.
We entered:

283
Configuring the Frame Relay Interface 1 IP Address Select IP Addresses against frame relay interface 1.
We entered:

284
We entered:

285
286
Configuring Static IP Routes: Because the AS/400 does not support RouteD over frame relay interfaces, we could not use this to propagate route information to the 2210. We therefore have to define static routes on each of the 2210s. Select Static Routes from the IP folder.
We Added the following static routes:

Destination network 9.24.104.0 with a Destination mask of 255.255.255.0. Next hop address 1: 10.1.2.1. Cost 1: 1. Next hop address 2: 10.1.5.2. Cost 2: 5. Next hop address
10.1.2.1 is the AS/400 s frame relay interface. 10.1.5.2 is 2210B s frame relay interface. This route entry provides the backup route should the direct link to RALYAS4C fail.
287


The token-ring interface The frame relay interface to the AS/400 The frame relay interface to 2210B
We selected:

288
289
Configuring IPX on the Frame Relay Interface 1 1. Check Enabled against the frame relay interface 1. 2. Select Configure against the frame relay interface 1.
290
291

We selected:

Enable APPN network node. Set the Network ID to USIBMRA . Set the Control point name to HPR2210A .
292
We selected:

Define Port for interface 0 . Define Port for interface 1 . Define Port for interface 2 . Used the Scroll bar to move to Serial interface 3. Define Port for interface 3 . Port configurations
As we are using HPR in this scenario, we were able to accept all the defaults from Configure port selection. So we now move directly to configuring the link stations.
293
Token-ring interface 0 APPN Configuration: We used token-ring interface 0 to connect to the AS/400 RALYAS4A. Select Link Stations against token-ring interface 0.
From General-1 we selected a Link station name of RALYAS4A .
294
Select General-2 to configure the adjacent node name and node type.
A MAC address of adjacent node of 400000000150 (see Token-Ring Line Description on page 255). Adjacent node type APPN end node . Pressed Add .
295
From General-1 we:

Set the Link station name to RAL5494A . De-selected Allow CP-CP sessions on this link.
296

Station address 10 (see Figure 229 on page 257). Adjacent node type LEN end node . Fully-qualified CP name USIBMRA.RAL5494A (see Figure 230 on page 258). Pressed Add .
297
298
Select General-2 to configure the adjacent node type.

299
Interface 2 APPN Configuration: We used the serial interface 2 to connect to 2210B. Select Link Stations against PVC 777.
From General-1 we selected a Link station name of HPR2210B .
300

301

Figure 265. Saving 2210A Configuration
We selected:

Save configuration as... A Configuration name of 2210A in the config.cdb database. OK . Configure once more. Create router configuration... A configuration file name of 2210A.CFG .
302
11.5.2 IBM 2210B Configuration


We selected a 2210 Model 24E with an empty slot.
303


An Ethernet interface A frame relay interface to the AS/400 A frame relay interface to 2210A An SDLC interface to the IBM 5494
Configuring the Ethernet Interface 1. From the Devices folder select Interfaces . 2. Select Configure against the Ethernet interface.
Figure 267. Configuring the 2210 Ethernet Interface
We set the MAC address to 1A002210000B.
304

305
306
We added:

307
We added:

308
Configuring the Serial Frame Relay Interface 2: We used serial interface 2 to connect to 2210A. 1. Select Frame Relay from the drop-down list against interface 2. 2. Select Configure against serial interface 2.
Figure 272. Configuring the 2210 Serial Interface to 2210A

309
310
We added:

311
We added:

Protocol IP to Circuit Number 555 with an address of 10.1.5.2. Protocol IPX to Circuit Number 666 with an IPX host number of 00000002210B. Pressed Add after selection.
312

313

The Ethernet interface The frame relay interface to the AS/400 The frame relay interface to 2210A
We also added a default route. Configuring the Ethernet Interface IP Address 1. Select Interfaces from the IP folder. 2. Select IP Addresses against Ethernet interface 0.
Figure 277. Ethernet Interface IP Address 2210 Configuration
We entered:

314
We entered:

315
We entered:

316
317
Configuring Static IP Routes: Because the AS/400 does not support RouteD over frame relay interfaces, we could not use this to propagate route information to the 2210. We therefore have to define static routes on each of the 2210s. Select Static Routes from the IP folder.
We added the following static routes:

Destination network 9.24.104.0 with a Destination mask of 255.255.255.0. Next hop address 1: 10.1.6.1. Cost 1: 1. Next hop address 2: 10.1.5.1. Cost 2: 5. Next hop address
10.1.6.1 is the AS/400 s frame relay interface. 10.1.5.1 is 2210A s frame relay interface. This route entry provides the backup route should the direct link to RALYAS4C fail.
318


The Ethernet interface The frame relay interface to the AS/400 The frame relay interface to 2210A
We selected:

Enable IPX Entered a Host number of 00000002210B
319
Configuring IPX on the Ethernet Interface 1. Select Interfaces from the IPX folder. 2. Check Enabled against the Ethernet interface 0. 3. Select Configure against Ethernet interface 0.
Framing type It is important that the Ethernet framing type selected matches that of any IPX clients or servers on this Ethernet segment.
320
321
322

We selected:

Enable APPN network node. Set the Network ID to USIBMRA . Set the Control point name to HPR2210B .
323
We selected:

Define Port for interface 0 . Define Port for interface 1 . Define Port for interface 2 . Used the scroll bar to move to Serial interface 3 and selected Define Port for interface 3 . Port configurations
As we are using HPR in this scenario. We were able to accept all the defaults from Configure port selection. So we now move directly to configuring the link stations.
324
From General-1 we:

Set the Link station name to RAL5494B . De-selected Allow CP-CP sessions on this link .
325

Station address 20 (see Figure 231 on page 259). Adjacent node type LEN end node . Fully-qualified CP name USIBMRA.RAL5494B (see Figure 232 on page 260). Pressed Add .
326
327
Figure 291. Link Station Configuration for 2210 Interface 1 continued

328
Interface 2 APPN Configuration: We used the serial interface 2 to connect to 2210A. Select Link Stations against PVC 777.
From General-1 we selected a Link station name of HPR2210A .
329

330

We selected:

Save configuration as... A Configuration name of 2210B in the config.cdb database. OK . Selected Configure once more Create router configuration... A configuration file name of 2210B.CFG .
331

Before we can start the APPN, IP and IPX protocols on the AS/400, we have to vary on (activate) the frame relay network interfaces, frame relay lines and the token-ring line descriptions on RALYAS4C, and the network server and token-ring line description on RALYAS4A. To vary on the frame relay interfaces on RALYAS4C, we used the following command:
VRYCFG CFGOBJ(FR_RELAY_A FR_RELAY_B) CFGTYPE(*NWI) STATUS(*ON)

The above command will also activate (vary on) the associated line descriptions. Should it be necessary to vary on the line descriptions separately, we can use the command:
VRYCFG CFGOBJ(FR_HPR_A FR_HPR_B FR_TCPIP_A FR_TCPIP_B FR_IPX_A FR_IPX_B) CFGTYPE(*LIN) STATUS(*ON)

To vary on the network server on RALYAS4A, we used the following command:
VRYCFG CFGOBJ(IPCSBASE) CFGTYPE(*NWS) STATUS(*ON)

The above command will also activate (vary on) the associated line description. Should it be necessary to vary on the line description separately, we can use the command:

To start the APPN session between RALYAS4C and the 2210s, we used the following commands to vary on (activate) the APPC controller descriptions:
VRYCFG CFGOBJ(HPR2210A) CFGTYPE(*CTL) STATUS(*ON) VRYCFG CFGOBJ(HPR2210B) CFGTYPE(*CTL) STATUS(*ON)

To start the APPN session between RALYAS4A and the 2210, we used the following commands to vary on (activate) the APPC controller description:
VRYCFG CFGOBJ(HPR2210A) CFGTYPE(*CTL) STATUS(*ON)

The APPC devices for the 2210 CP sessions and the 5494 remote workstation controller will be autocreated by the AS/400 when these sessions become active.
332
We can see the status of the RALYAS4C AS/400 frame relay interfaces and associated configuration objects using the command:
WRKCFGSTS CFGTYPE(*NWI) CFGD(FR_RELAY_*)

Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FR_RELAY_A FR_HPR_A HPR2210A HPR2210A FR_RELAY_B FR_HPR_B HPR2210B HPR2210B Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE -------------Job--------------
F23=More options
F24=More keys
Figure 295. Work with Configuration Status. RALYAS4C Frame Relay Interfaces.
We can see the status of the RALYAS4A AS/400 network server and associated configuration objects using the command:
WRKCFGSTS CFGTYPE(*NWS) CFGD(IPCSBASE)

Work with Configuration Status 05/05/98 Position to . . . . . Starting characters RALYAS4A 11:21:05
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description IPCSBASE TOKENRING HPR2210A HPR2210A Status ACTIVE ACTIVE ACTIVE ACTIVE -------------Job--------------
F23=More options
F24=More keys
Figure 296. Work with Configuration Status. RALYAS4A Network Server.
333
We can see the status of the RALYAS4C AS/400 APPN information using the command WRKAPPNSTS.
Work with APPN Status System: Select one of the following: 1. Work with APPN locations 2. Work with RTP connections RALYAS4C
Selection or command ===> 1 F3=Exit F4=Prompt F9=Retrieve F12=Cancel
Figure 297. RALYAS4C Work with APPN Status
Select option 1, to Work with APPN locations.
Work with APPN Locations System: Type options, press Enter. 5=Work with sessions 8=Work with RTP connections 12=Work with configuration status -------Remote------Location Network Name ID HPR2210A RAL5494A HPR2210B HPR2210B RAL5494B USIBMRA USIBMRA RALYAS4C RALYAS4C USIBMRA USIBMRA 2 2 3 4 Bottom USIBMRA USIBMRA -------Local-------Location Network Name ID RALYAS4C RALYAS4C USIBMRA USIBMRA RALYAS4C
Opt
Controller HPR2210A
Number of Sessions 2 2 1 2
Parameters or command ===> F3=Exit F4=Prompt F5=Refresh F6=Print list F16=Repeat position to F17=Position to
F9=Retrieve
F12=Cancel
Figure 298. RALYAS4C Work with APPN Locations
In Figure 298 we can see the following APPN sessions:
1 2 3 4
CP sessions with 2210A APPN sessions with 5494A via the controller (PU) HPR2210A CP sessions with 2210B APPN sessions with 5494B via the controller (PU) HPR2210B
We can see the status of the RALYAS4A AS/400 APPN information using the command WRKAPPNSTS. As above, we took option 1 to Work with APPN locations.
334
Work with APPN Locations System: Type options, press Enter. 5=Work with sessions 8=Work with RTP connections 12=Work with configuration status -------Remote------Location Network Name ID HPR2210A USIBMRA -------Local-------Location Network Name ID RALYAS4A USIBMRA RALYAS4A
Opt
Controller HPR2210A
Number of Sessions 2
Bottom Parameters or command ===> F3=Exit F4=Prompt F5=Refresh F6=Print list F16=Repeat position to F17=Position to
F9=Retrieve
F12=Cancel
Figure 299. RALYAS4A Work with APPN Locations
In Figure 299 we can see the CP sessions with HPR2210A. To see the RTP connections on RALYAS4C, we entered the command WRKAPPNSTS again, but this time selected option 2 to Work with RTP connections.
Work with RTP Connections System: RALYAS4C Type options, press Enter. 5=Work with sessions 8=Work with APPN locations 9=Path switch 10=End connection 12=Work with configuration status ... ----RTP Partner----Control Network Class of Number of Opt Controller Point ID TCID Service Sessions HPR2210A HPR2210A USIBMRA 0000F8 #CONNECT 2 1 HPR2210B HPR2210B USIBMRA 000038 #CONNECT 2 2
Figure 300. RALYAS4C Work with RTP Connections.
In Figure 300 we can see that there are 2 RTP partners:
1 HPR2210A via the HPR2210A APPC controller 2 HPR2210B via the HPR2210B APPC controller
335
If we now break the link between RALYAS4C and the 2210A, then update the RALYAS4C Work with APPN Locations screen, we see the following.
Work with APPN Locations System: Type options, press Enter. 5=Work with sessions 8=Work with RTP connections 12=Work with configuration status -------Remote------Location Network Name ID HPR2210A HPR2210B HPR2210B RAL5494A RAL5494B USIBMRA USIBMRA USIBMRA RALYAS4C RALYAS4C RALYAS4C USIBMRA USIBMRA USIBMRA 2 1 1 Bottom Parameters or command ===> F3=Exit F4=Prompt F5=Refresh F6=Print list F16=Repeat position to F17=Position to USIBMRA -------Local-------Location Network Name ID RALYAS4C USIBMRA RALYAS4C
Opt
Controller HPR2210A
F9=Retrieve
F12=Cancel
In Figure 301 we can see that the APPN session to RAL5494A has been taken over by HPR2210B. If we update the RALYAS4C Work with RTP connections screen we see the following.
Work with RTP Connections System: RALYAS4C Type options, press Enter. 5=Work with sessions 8=Work with APPN locations 9=Path switch 10=End connection 12=Work with configuration status ... ----RTP Partner----Control Network Class of Number of Opt Controller Point ID TCID Service Sessions HPR2210B HPR2210A USIBMRA 000030 #CONNECT 2 1 HPR2210B USIBMRA 000108 #CONNECT 2 2
Figure 302. RALYAS4C AS/400 Network Attributes
In Figure 302 we can see that there are still two RTP partners but both are now via the HPR2210B APPC controller.
1 With HPR2210A 2 With HPR2210B

The following screens were captured at the 2210A router. In Figure 303 on page 337, the list rtp_connections command displays the APPN RTP connections for which the 2210 is a partner.
336
*t 5 CGW Operator Console +prot appn APPN GWCON APPN >list rtp_connections RTP PARTNER TABLE: Remote Partner Name Remote Boundary Name TG Number ====================================================== USIBMRA.RALYAS4C USIBMRA.RALYAS4C -1 RTP CONNECTION TABLE: TCID CP Name ISR APPC Pathswitch Alive
COS TPF
TG Numbe
================================================================================ 319F1C48 31A3BF70 31A47E78 APPN > USIBMRA.RALYAS4C USIBMRA.HPR2210B USIBMRA.HPR2210B 2 0 0 0 1 1 180 180 180 180 180 180 #CONNECT CPSVCMG CPSVCMG 0 21 21
Figure 303. 2210A RTP Connections
In Figure 304, the list cp-cp sessions command displays the APPN CP-CP sessions for which the 2210 is a partner.
APPN >list cp-cp sessions CP Name Type Status Connwinner ID Conloser ID ======================================================================== USIBMRA.RALYAS4C NN Active B924DAFE B924DAFA USIBMRA.HPR2210B NN Active B924DB39 B924DB38 USIBMRA.RALYAS4A EN Active B924DAE2 B924DADE APPN >
Figure 304. 2210A CP-CP Sessions
APPN >list isr_sessions Adjacent CP Name TG Number ISR Sessions =============================================== USIBMRA.RALYAS4A 1 0 USIBMRA.RALYAS4C 1 0 USIBMRA.RAL5494A 0 1 APPN >
Figure 305. 2210A ISR Sessions
Figure 305 shows the ISR session for the passthru session that was active between RALYAS4A and RALYAS4C as well as the 5494 session to RALYAS4C.
337

To start the frame relay TCP/IP interfaces on RALYAS4C, we used the following commands:
STRTCPIFC INTNETADR( 1 0 . 1 . 2 . 1 ) STRTCPIFC INTNETADR( 1 0 . 1 . 6 . 1 )

To start the token-ring TCP/IP interface on RALYAS4A, we used the following command:
Interface not started You will receive this message if the TCP/IP support is not started on the AS/400. You can start TCP/IP on the system with the STRTCP command.
Starting a TCP/IP interface creates a *NET controller and a *NET device description under the relevant line description. We used the WRKCFGSTS CFGTYPE(*NWI) CFGD(FR_RELAY*) command on RALYAS4C to verify this.
RALYAS4C 16:57:44
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FR_RELAY_A FR_TCPIP_A FR_TCPNET FR_TCPCP FR_HPR_A HPR2210A HPR2210A FR_RELAY_B FR_TCPIP_B FR_TCNET00 FR_TCPCP00 FR_HPR_B HPR2210B HPR2210B Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE -------------Job--------------
QTCP
QTCP
069747
QTCP
QTCP
069747
F23=More options
F24=More keys
Figure 306. RALYAS4C Work with Configuration Status. TCP/IP Configuration.
338
We checked the status of the RALYAS4C TCP/IP interfaces with the NETSTAT *IFC command.
Work with TCP/IP Interface Status System: Type options, press Enter. 5=Display details 8=Display associated routes 9=Start 10=End 12=Work with configuration status 14=Display multicast groups Internet Address 9.24.104.162 10.1.2.1 10.1.6.1 127.0.0.1 Network Address 9.24.104.0 10.1.2.0 10.1.6.0 127.0.0.0 Line Description TRN2619C FR_TCPIP_A FR_TCPIP_B *LOOPBACK Interface Status Active Active Active Active RALYAS4C
Opt
Bottom F12=Cancel
Figure 307. RALYAS4C Work with TCP/IP Interface Status
We checked the status of the RALYAS4C TCP/IP routes with the NETSTAT *RTE command.
Display TCP/IP Route Information System: Type options, press Enter. 5=Display details Route Destination 9.24.104.0 10.1.6.0 10.1.2.0 10.1.3.0 10.1.3.0 10.1.4.0 10.1.4.0 127.0.0.0 224.0.0.0 224.0.0.0 *DFTROUTE Subnet Mask 255.255.255.0 255.255.255.0 255.255.255.0 255.255.255.0 255.255.255.0 255.255.255.0 255.255.255.0 255.0.0.0 240.0.0.0 240.0.0.0 *NONE Next Hop *DIRECT *DIRECT *DIRECT 10.1.2.2 10.1.6.2 10.1.6.2 10.1.2.2 *DIRECT *DIRECT *DIRECT 9.24.104.1 Route Available *YES *YES 1 *YES 1 *YES 2 *YES 3 *YES 4 *YES 5 *YES *YES *YES *YES Bottom F3=Exit F5=Refresh F11=Display route type F6=Print list F12=Cancel F9=Command line F13=Sort by column F24=More keys RALYAS4C
Opt
Figure 308. RALYAS4C Display TCP/IP Route Information 1/2
We can press F11 to display the route types.
339
Display TCP/IP Route Information System: Type options, press Enter. 5=Display details Route Destination 9.24.104.0 10.1.6.0 10.1.2.0 10.1.3.0 10.1.3.0 10.1.4.0 10.1.4.0 127.0.0.0 224.0.0.0 224.0.0.0 *DFTROUTE Type of Service *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL Route MTU 16388 1585 1585 576 576 576 576 576 1989 16388 576 Route Type *DIRECT *DIRECT *DIRECT *SUBNET *SUBNET *SUBNET *SUBNET *DIRECT *DIRECT *DIRECT *DFTROUTE Route Source *CFG *CFG 1 *CFG 1 *CFG 2 *CFG 3 *CFG 4 *CFG 5 *CFG *CFG *CFG *CFG Bottom F11=Display next hop F18=Bottom RALYAS4C
Opt
1 10.1.6.0 and 10.1.2.0 These routes are the result of adding the frame relay
TCP/IP interfaces 10.1.6.1 and 10.1.2.1.
2 10.1.3.0 3 10.1.3.0 4 10.1.4.0 5 10.1.4.0
This network can be found via the 2210A frame relay interface (10.1.2.2). This is the backup connection to 10.1.3.0 that can be found via the HPR2210B frame relay interface (10.1.6.2). This network can be found via the 2210B frame relay interface (10.1.6.2). This is the backup connection to 10.1.4.0 that can be found via the HPR2210A frame relay interface (10.1.2.2).
340
We checked the status of the RALYAS4A TCP/IP interfaces with the NETSTAT *RTE command.
Display TCP/IP Route Information System: Type options, press Enter. 5=Display details Route Destination 9.24.104.0 10.1.3.0 10.1.2.0 10.1.5.0 10.1.6.0 127.0.0.0 224.0.0.0 9.0.0.0 Subnet Mask 255.255.255.0 255.255.255.0 255.255.255.0 255.255.255.0 255.255.255.0 255.0.0.0 240.0.0.0 255.0.0.0 Next Hop 10.1.3.1 *DIRECT 10.1.3.1 10.1.3.1 10.1.3.1 *DIRECT *DIRECT 10.1.3.1 Route Available *YES *YES *YES 3 *YES 3 *YES 3 *YES *YES *YES RALYAS4A
Opt
Figure 310. RALYAS4A Display TCP/IP Route Information 1/2
Display TCP/IP Route Information System: Type options, press Enter. 5=Display details Route Destination 9.24.104.0 10.1.3.0 10.1.2.0 10.1.5.0 10.1.6.0 127.0.0.0 224.0.0.0 9.0.0.0 Type of Service *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL Route MTU 576 1989 1989 1989 1989 576 1989 576 Route Type *SUBNET *DIRECT *SUBNET *SUBNET *SUBNET *DIRECT *DIRECT *DIRECT Route Source *CFG *CFG *RIP 3 *RIP 3 *RIP 3 *CFG *CFG *CFG Bottom F11=Display next hop F18=Bottom RALYAS4A
Opt
All these networks
3 have been discovered via the 2210A interface 10.1.3.1.
341
D:\>ftp 9.24.104.121 IBM TCP/IP for OS/2 - FTP Client ver 08:36:08 on Jul 22 1996 Connected to 9.24.104.121. 220-QTCP at 9.24.104.121. 220 Connection will close if idle more than 5 minutes. Name (9.24.104.121): mick 331 Enter password. Password: ....... 230 MICK logged on. ftp>
Figure 312. Using FTP to Verify the Connection Status
The following screen was captured at the 2210A router. In Figure 313, the dump command displays the 2210 TCP/IP route table with the link to RALYAS4C active.
*t 5 CGW Operator Console +p ip IP>dump Type Dest net Sbnt Stat* Sbnt Dir* Dir* Dir* RIP 9.0.0.0 9.24.104.0 10.0.0.0 10.1.2.0 10.1.3.0 10.1.5.0 10.1.6.0
Mask FF000000 FFFFFF00 FF000000 FFFFFF00 FFFFFF00 FFFFFF00 FFFFFF00
Cost 1 1 1 1 1 1 2
Age 31 21 1 21 38 58 20
Next hop(s) None 10.1.2.1 None FR/0 TKR/0 FR/1 10.1.5.2
Figure 313. 2210A TCP/IP Route Information 1/2
In Figure 314, the dump command displays the 2210 TCP/IP route table with the link to RALYAS4C broken.
IP>dump Type Dest net Sbnt Stat* Sbnt Del Dir* Dir* RIP 9.0.0.0 9.24.104.0 10.0.0.0 10.1.2.0 10.1.3.0 10.1.5.0 10.1.6.0
Mask FF000000 FFFFFF00 FF000000 FFFFFF00 FFFFFF00 FFFFFF00 FFFFFF00
Cost 1 5 1 16 1 1 2
Age 112 6 82 190 119 140 10
Next hop(s) None 10.1.5.2 None None TKR/0 FR/1 10.1.5.2
Figure 314. 2210A TCP/IP Route Information 2/2
342
From Figure 314 note that the route to the 9.24.104 network is via 2210B (10.1.5.2).

First we must start IPX. On RALYAS4C we used the following command to do this:
The above command will also start the token-ring and frame relay IPX circuits. Should it be necessary to start the circuits separately, use the following commands.
STRIPXCCT CCTNAME(TRN2619C) STRIPXCCT CCTNAME(FR_IPX_A) STRIPXCCT CCTNAME(FR_IPX_B)

Starting an IPX circuit creates a *NET controller and a *NET device description under the relevant line description. For the frame relay interface on RALYAS4C we used the WRKCFGSTS CFGTYPE(*NWI) CFGD(FR_RELAY*) command to verify this.
RALYAS4C 16:57:44
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FR_RELAY_A FR_TCPIP_A FR_TCPNET FR_TCPCP FR_IPX_A FR_IPNET FR_IPIPX FR_HPR_A HPR2210A HPR2210A FR_RELAY_B FR_TCPIP_B FR_TCNET00 FR_TCPCP00 FR_IPX_B FR_IPNET00 FR_IPIPX00 FR_HPR_B HPR2210B HPR2210B Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE -------------Job--------------
QTCP
QTCP
069747
QIPX
QSYS
069812
QTCP
QTCP
069747
QIPX
QSYS
069812
F23=More options
F24=More keys
Figure 315. RALYAS4C Work with Configuration Status. IPX Configuration.
343
Work with IPX Circuits System: Type options, press Enter. 1=Add 2=Change 4=Remove 8=Display associated routes Circuit Name FR_IPX_A FR_IPX_B TRN2619C 5=Display 9=Start Line Description FR_IPX_A FR_IPX_B TRN2619C RALYAS4C
7=Display associated services 10=End Line Type *FR *FR *TRLAN Circuit Status Active Active Active
Opt
F3=Exit
F5=Refresh
F6=Print list
F12=Cancel
F17=Top
F18=Bottom
Figure 316. RALYAS4C Work with IPX Circuits
Type options, press Enter. 5=Display details Service name BACKUP_SERVER FERGUS_NW41 MICKS_SERVER BSER4.00-6.10_111> TS@BACKUP_SERVER BACKUP_SERVER FERGUS_NW41 WTR05371 BACKUP_SERVER FERGUS_TREE______> MICKS_DIR________> WIM_TREE_________> F5=Refresh Service Type *FILESVR *FILESVR *FILESVR 004B 0077 0107 0107 0130 023F 026B 026B 026B Remote Network 11111111 35476764 305C27F6 11111111 11111111 11111111 35476764 00000009 11111111 35476764 305C27F6 11111111 F12=Cancel Hops to Service 1 1 1 1 1 1 1 1 1 1 1 1 Service Source *SAP *SAP *SAP *SAP *SAP *SAP *SAP *SAP *SAP *SAP *SAP *SAP
Opt
F3=Exit
F6=Print list
F17=Top
F18=Bottom
Figure 317. RALYAS4C Work with IPX Services Information
344
TOKENCS-DOS-200: Inserting into the ring. Please Wait. Int 2, Port A20, Mem D0000, Mem D8000, Node Address 8005AE475B9 M Max Frame 4210 bytes, Line Speed 16 Mbps Board 1, Frame TOKEN-RING, MSB Mode NetWare IPX/SPX Protocol v3.01 (941031) (C) Copyright 1990-1994 Novell, Inc. All Rights Reserved. IPX RETRY COUNT 50 Bound to logical board 1 (TOKENCS) : Protocol ID E0 NetWare Source Routing Driver v2.21 (940315) (C) Copyright 1993 Novell Inc. All Rights Reserved. ROUTE-DOS-200: Current ROUTE.com parameters for Board #1 are: DEFault Node (Unknown) Addresses are sent SINGLE ROUTE Broadcast. Broadcast (FFFF FFFF FFFF) Addresses are sent SINGLE ROUTE Broadcast. Multicast (C000 xxxx xxxx) Addresses are sent SINGLE ROUTE Broadcast. Maximum HOPS = 7 Bridges; NODES = 16; Aging TIME = 10 Seconds. This Ring Only (TRO) Count = 0; Extra Transmit (XTX) Count = 2. VLM.EXE - NetWare virtual loadable module manager (C) Copyright 1994 Novell, Inc. All Rights Reserved. Patent pending. v1.20 (941108)
345
346
Chapter 12. Multiprotocol Central Site Connectivity

In this scenario we build a multiprotocol network using two IBM 2216 routers with the objective of providing central site to central site multiprotocol connectivity. We will use HPR between the routers for SNA/APPN connectivity. The scenario also provides central site to central site TCP/IP and IPX connectivity. The objectives of this scenario are as follows:
To interconnect two central site LANs for the transport of SNA/APPN, TCP/IP and IPX To configure HPR for the transport of SNA/APPN To connect an AS/400 at each site to the site IBM 2216 using a LAN link

APPN/HPR network to support SNA connections TCP/IP network IPX network
Figure 319. Central Site Connectivity Using Two I B M 2216 Routers
347
Routers Two IBM 2216 Nways Multiaccess Connectors, with MAS V2R2.
Frame relay WAN link between the two IBM 2216s The speed of the connection is 64 Kbps. We used a modem eliminator with V.35 interfaces.
AS/400 systems With OS/400 V4R2.
348

In our multiprotocol router network we defined HPR to support the SNA/APPN traffic between the AS/400s. Figure 320 shows the APPN network including the network ID and CP names. The two 2216s and the two AS/400s are all configured as APPN network nodes.
Figure 320. Central Site Connectivity. APPN Network.

In this section we show the AS/400 APPN network definitions. AS/400 Network Attributes: The AS/400 APPN node type, network ID and CP name are defined in the system network attributes. To display the network attributes for RALYAS4C, use the command DSPNETA.
349
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
: : : : : : : : : : : :
RALYAS4C
*ANY More...
From Figure 321 take note of the local network ID and local control point name. We enabled the HPR tower function on RALYAS4C. The parameter for this is on the last screen of the network attributes as shown in Figure 322.
Display Network Attributes System: Maximum hop count . . . . . . . . DDM request access . . . . . . . . Client request access . . . . . . Default ISDN network type . . . . Default ISDN connection list . . . Allow AnyNet support . . . . . . . Network server domain . . . . . . Allow APPN virtual support . . . . Allow HPR transport tower support Virtual controller autocreate APPC HPR path switch timers: Network priority . . . . . . . . High priority . . . . . . . . . Medium priority . . . . . . . . Low priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . device limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : : : : : 16 *OBJAUT *OBJAUT QDCCNNLANY *YES S100CBDM *NO *YES 100 1 2 4 8 RALYAS4C
Token-Ring Line Description: For token-ring, the physical connection between an AS/400 and a network is defined using a line description . The token-ring adapter that we used in this scenario was associated with a File
350
Server IO Processor (FSIOP). We therefore first created a network server description then the actual line description.

The important parameters for the network server are: Network server description (NWSD) The unique name for this network server description Resource name (RSRCNAME) Use the Work with Hardware Resource (WRKHDWSC) command with *CMN to find the correct resource name for the FSIOP. Network server type (TYPE) We used the FSIOP only as a LAN adapter. Start NetBIOS (STRNTB) We didn t use NetBIOS support.
CALL QCMD If entered as shown, the command above will overflow the number of command entry lines made available. We gain extra lines by entering the command CALL QCMD.
The important parameters in the token-ring line description are: Line description (LIND) The unique name for this line description. Resource name (RSRCNAME) For this scenario we were using an FSIOP to connect to the network and therefore specify *NWSD as the resource name. Network server description (NWS) Specifies the network server to which this line is attached and the port to use. Line speed (LINESPEED) Specifies the line speed in bits per second (bps). Local adapter address (ADPTADR) Specifies the local system s token-ring adapter address. Note: The APPC controller and APPC device descriptions are autocreated when the link between the AS/400 and 2216 becomes active provided that the QAUTOCFG system value is set to 1 (on) and the AUTOCRTCTL parameter in the token-ring line description is set to *YES. Alternatively, we could have created the APPC controller description for 2216A using the following command:
351
CRTCTLAPPC CTLD(APPN216A) LINKTYPE(*LAN) SWTLINLST(TOKENRING) RMTCPNAME(APPN216A) ADPTADR(40002216000A) NODETYPE(*NETNODE) TEXT( APPC Controller for 2216A )

The AS/400 APPN node type, network ID and CP name are defined in the system network attributes. To display the network attributes for RALYAS4A, use the command DSPNETA.
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
: : : : : : : : : : : :
System: RALYAS4A USIBMRA RALYAS4A RALYAS4A BLANK *NETNODE *NONE *NONE 200 128 *LCLNETID
RALYAS4A
*ANY More...
From Figure 323 take note of the local network ID and local control point name. We enabled the HPR tower function on RALYAS4A. The parameter for this is shown on the last screen of the network attributes as shown in Figure 324 on page 353.
352
Display Network Attributes System: Maximum hop count . . . . . . . . DDM request access . . . . . . . . Client request access . . . . . . Default ISDN network type . . . . Default ISDN connection list . . . Allow AnyNet support . . . . . . . Network server domain . . . . . . Allow APPN virtual support . . . . Allow HPR transport tower support Virtual controller autocreate APPC HPR path switch timers: Network priority . . . . . . . . High priority . . . . . . . . . Medium priority . . . . . . . . Low priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . device limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : : : : : 16 *OBJAUT *OBJAUT QDCCNNLANY *YES S100CBDM *NO *YES 100 1 2 4 8 RALYAS4A
Token-Ring Line Description: For token-ring, the physical connection between an AS/400 and a network is defined using a line description . The token-ring adapter that we used in this scenario was associated with an Integrated PC Server (IPCS). We therefore first created a network server description then the actual line description.

The important parameters for the network server are: Network server description (NWSD) The unique name for this network server description. Resource name (RSRCNAME) Use the Work with Hardware Resource (WRKHDWSC) command with *CMN to find the correct resource name for the IPCS. Network server type (TYPE) We used the IPCS only as a LAN adapter. Start NetBIOS (STRNTB) We didn t use NetBIOS support.
CRTLINTRN LIND(TOKENRING) RSRCNAME(*NWSD) NWS(IPCSBASE 1) LINESPEED(16M) MAXFRAME(1994) ADPTADR(400000000150)

353
TEXT( Token Ring Line on IPCSBASE ) AUTOCRTCTL(*YES)

The important parameters in the token-ring line description are: Line description (LIND) The unique name for this line description. Resource name (RSRCNAME) For this scenario we were using an IPCS to connect to the network and therefore specify *NWSD as the resource name. Network server description (NWS) Specifies the network server to which this line is attached and the port to use. Line speed (LINESPEED) Specifies the line speed in bits per second (bps). Local adapter address (ADPTADR) Specifies the local system s token-ring adapter address. Note: The APPC controller and APPC device descriptions are autocreated when the link between the AS/400 and 2216 becomes active provided that the QAUTOCFG system value is set to 1 (on) and the AUTOCRTCTL parameter in the token-ring line description is set to *YES. Alternatively, we could have created the APPC controller description for 2216A using the following command:
CRTCTLAPPC CTLD(APPN216B) LINKTYPE(*LAN) SWTLINLST(TOKENRING) RMTCPNAME(APPN216B) ADPTADR(40002216000B) NODETYPE(*NETNODE) TEXT( APPC Controller for 2216B )
CALL QCMD If entered as shown, the command above will overflow the number of command entry lines made available. We gain extra lines by entering the command CALL QCMD.
354

In our multiprotocol router network we defined TCP/IP to support TCP/IP traffic between an IP client and an IP host. Figure 325 shows the TCP/IP network including the network addresses.
Figure 325. Central Site Connectivity. TCP/IP Network.
12.3.1 AS/400 TCP/IP Definitions (RALYAS4C)

In this section we show the AS/400 TCP/IP network definitions. For this scenario the AS/400 is not in the route between the IP client and host. Therefore, if there is no requirement to use AS/400 TCP/IP, this section can be skipped. For this scenario we created:

A TCP/IP interface A TCP/IP route Token-ring line
TCP/IP Interface Definition: To define the token-ring TCP/IP interface on RALYAS4C, we used the following command:
ADDTCPIFC INTNETADR( 1 0 . 1 . 1 . 2 ) LIND(TOKENRING) SUBNETMASK(255.255.255.0)
355
We used RouteD with the default parameters. Had we not used RouteD, we could have instead defined a route to the 10.1.3 network via the 2216A router with the following command:
356
12.3.2 AS/400 TCP/IP Definitions (RALYAS4A)

In this section we show the AS/400 TCP/IP network definitions. For this scenario the AS/400 is not in the route between the IP client and host. Therefore, if there is no requirement to use AS/400 TCP/IP, this section can be skipped. For this scenario we created:

A TCP/IP interface A TCP/IP route Token-ring line
TCP/IP Interface Definition: To define the token-ring TCP/IP interface on RALYAS4A, we used the following command:
ADDTCPIFC INTNETADR(10.1.3.150) LIND(TOKENRING) SUBNETMASK(255.255.255.0)

We used RouteD with the default parameters. Had we not used RouteD, we could have instead defined a route to the 10.1.1 network via the 2216B router with the following command:
12.3.3 IP Client Setup for TCP/IP

The Thinkpad Windows 95 TCP/IP was configured as follows: IP Address Subnet Mask Default Gateway 10.1.1.47 255.255.255.0 10.1.1.1 This points to 2216A s token-ring interface.
357

The IP host TCP/IP was configured as follows: IP Address Subnet Mask Route to 10.1.1.0 10.1.3.121 255.255.255.0 10.1.3.1 This route points to the token-ring interface of 2216B.
358

The following figure shows the IPX network layout as well as the IP network and addresses involved. The objective is for the Novell client to reach the Novell server.
Figure 326. Central Site Connectivity. IPX Network.
12.4.1 AS/400 IPX Definitions (RALYAS4C)


An IPX description An IPX circuit Token-ring line
IPX Description: The IPX description is a required object and defines global (system wide) IPX configuration values. To define the IPX description on RALYAS4C, we used the following command:
359


The important parameters in an IPX circuit are: Circuit name (CCTNAME) We used the line description name for the circuit name. Line description (LIND) This is the line description associated with the circuit. IPX network number (IPXNETNBR) This parameter defines the external network number for this LAN/WAN connection. Consult your network administrator to determine the value to be used. Attention If there are devices on the network that are broadcasting the wrong network number, the IPX circuit won t start. You can check the Novell server system console for messages relating to this.
360
12.4.2 AS/400 IPX Definitions (RALYAS4A)


An IPX description An IPX circuit Token-ring line
IPX Description: The IPX description is a required object and defines global (system wide) IPX configuration values. To define the IPX description on RALYAS4A, we used the following command:
CRTIPXD IPXD(RALYAS4C) IPXNETNBR(*RANDOM) IPXRTRNAME(RALYAS4A) TEXT( IPX Description for RALYAS4A )

The important parameters in an IPX description are: IPX description (IPXD) We used the system name for the IPX description name. IPX internal network number (IPXNETNBR) The IPX network number used for the AS/400 s internal IPX network must be unique to all other network numbers (internal and external) in this IPX internetwork. Contact the network administrator for the network number to use. IPX Circuit: An IPX circuit must be defined for each line over which IPX routing will be used. To define the token-ring IPX circuit on RALYAS4A, we used the following command:

The important parameters in an IPX circuit are: Circuit name (CCTNAME) We used the line description name for the circuit name. Line description (LIND) This is the line description associated with the circuit. IPX network number (IPXNETNBR) This parameter defines the external network number for this LAN/WAN connection. Consult your network administrator to determine the value to be used.
361
Attention If there are devices on the network that are broadcasting the wrong network number, the IPX circuit won t start. You can check the Novell Server system console for messages relating to this.
362

In this section we show the IBM 2216 router configurations that were used in this scenario.
12.5.1 2216A Configuration

In this section we show the IBM 2216 configuration using the MAS configuration program. Wherever possible we accepted the defaults. We therefore only show where parameters had to be entered or changed.
12.5.2

We selected:

363


A token-ring interface A PPP serial interface to 2216B
Configuring the Token-Ring Interface 1. From the Adapters folder select Interfaces . 2. Select Configure against the token-ring interface.
We selected:

364
Configuring the Serial PPP Interface 2: We used serial interface 2 to connect to 2216B. Select Configure against serial interface 2.
From General we selected encoding NRZI .
365

The token-ring interface The PPP interface to 2216B
We Entered:

366
We Entered:

367
368


The token-ring interface The PPP interface to 2216B
We selected:

369
Configuring IPX on the Token-Ring Interface 1. Select Interfaces from the IPX folder. 2. Check Enabled against token-ring interface 0. 3. Select Configure against token-ring interface 0.
370
Configuring IPX on the PPP Interface 1. Check Enabled against PPP interface 2. 2. Select Configure against PPP interface 2.
We entered an IPX network number of BBB . IPX network number The IPX network number used must be unique to all other network numbers (internal and external) in this IPX internetwork. Contact the network administrator for the network number to use. For our scenario, this network number must match 2216B s PPP interface network number.
371

Select General from APPN folder.
We selected:

Enable APPN network node . Set the Network ID to USIBMRA . Set the Control point name to APPN216A .
372
We selected:

Define Port for interface 0 . Define Port for interface 2 . Port Configuration
373
Token-ring interface 0 APPN Configuration: We used token-ring interface 0 to connect to RALYAS4C. Select Link Stations against token-ring interface 0.
374
Figure 339. 2210 Link Station Configuration for Interface 0 continued
A MAC address for adjacent node of 400000000000 (see Token-Ring Line Description on page 350). Adjacent node type of APPN network node .
375
Serial interface 2 APPN Configuration: We used serial interface 2 to connect to 2216B. Select Link Stations against serial interface 2.
From General-1 we set the Link station name to APPN216B .
376
Figure 341. 2216 Link Station Configuration for Interface 2 continued

377

We selected:

Save configuration as... A Configuration name of 2216A in the config.cdb database. OK . Selected Configure once more. Create router configuration... A configuration file name of 2216A.CFG .
378
12.5.3 2216B Configuration

12.5.4

We selected:

379


A token-ring interface A PPP serial interface to 2216A
We selected:

Cable type STP Set the MAC address to 40002216000B
380
Configuring the Serial PPP Interface 2: We used serial interface 2 to connect to the 2216A. Select Configure against serial interface 2.
From General we selected encoding NRZI .
381

The token-ring interface The PPP interface to 2216A
We Entered:

382
We Entered:

383
384


The token-ring interface The PPP interface to 2216A
We selected:

Enable IPX Entered a Host number of 00000002216B
385
386
Configuring IPX on the PPP Interface 1. Check Enabled against the PPP interface 2. 2. Select Configure against PPP interface 2.
We entered an IPX network number of BBB . IPX network number The IPX network number used must be unique to all other network numbers (internal and external) in this IPX internetwork. Contact the network administrator for the network number to use. For our scenario, this network number must match 2216A s PPP interface network number.
387

We selected:

Enable APPN network node . Set the Network ID to USIBMRA . Set the Control point name to APPN216B .
388
We selected:

Define Port for interface 0 . Define Port for interface 2 . Port Configuration
389
Token-ring interface 0 APPN Configuration: We used token-ring interface 0 to connect to RALYAS4A. Select Link Stations against token-ring interface 0.
From General-1 we set the Link station name to RALYAS4A .
390
A MAC address for adjacent node of 400000000150 (see Token-Ring Line Description on page 353). Adjacent node type of APPN network node .
391
From General-1 we set the Link station name to APPN216A .
392

393

Figure 358. Saving 2216B Configuration
We selected:

Save configuration as... A Configuration name of 2216B in the config.cdb database. OK . Selected Configure once more. Create router configuration... A configuration file name of 2216B.CFG .
394

Before we can start the APPN, IP and IPX protocols on the AS/400, we have to vary on (activate) the network servers and the token-ring line descriptions on RALYAS4C and RALYAS4A. To vary on the network server on RALYAS4C, we used the following command:




To start the APPN session between RALYAS4C and 2216A, we used the following command to vary on (activate) the APPC controller description:
VRYCFG CFGOBJ(APPN216A) CFGTYPE(*CTL) STATUS(*ON)

To start the APPN session between RALYAS4A and 2216B, we used the following command to vary on (activate) the APPC controller description:
VRYCFG CFGOBJ(APPN216B) CFGTYPE(*CTL) STATUS(*ON)

The APPN device descriptions for the 2216 CP-CP sessions will be autocreated by the AS/400s when the APPN sessions become active. We can see the status of the RALYAS4C network server and associated configuration objects using the command:
395
RALYAS4C 12:43:09
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FSIOP TOKENRING APPN216A APPN216A Status ACTIVE ACTIVE ACTIVE ACTIVE -------------Job--------------
F23=More options
F24=More keys
Figure 359. RALYAS4C Work with Configuration Status. APPN Configuration.
We can see the status of the RALYAS4A network server and associated configuration objects using the command:

Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description IPCSBASE TOKENRING APPN216B APPN216B Status ACTIVE ACTIVE ACTIVE ACTIVE -------------Job--------------
F23=More options
F24=More keys
Figure 360. RALYAS4A Work with Configuration Status. APPN Configuration.
396
We can see the status of the RALYAS4C AS/400 APPN information using the command WRKAPPNSTS.
Work with APPN Locations System: Type options, press Enter. 5=Work with sessions 8=Work with RTP connections 12=Work with configuration status -------Remote------Location Network Name ID -------Local-------Location Network Name ID RALYAS4C
Opt
Controller APPN216A
Number of Sessions
APPN216A
USIBMRA
RALYAS4C
USIBMRA
F9=Retrieve
F12=Cancel
In Figure 362 we can see the CP-CP sessions with 2216A. We can see the status of the RALYAS4A AS/400 APPN information using the command WRKAPPNSTS. As above, we took option 1 to Work with APPN locations.
397
Work with APPN Locations System: Type options, press Enter. 5=Work with sessions 8=Work with RTP connections 12=Work with configuration status -------Remote------Location Network Name ID -------Local-------Location Network Name ID RALYAS4A
Opt
Controller APPN216B
Number of Sessions
APPN216B
USIBMRA
RALYAS4A
USIBMRA
F9=Retrieve
F12=Cancel
In Figure 363 we can see the CP-CP sessions with 2216B. We can now start an HPR session between RALYAS4A and RALYAS4C, for example, by starting a pass-through session by entering the command STRPASTHR RALYAS4C at RALYAS4A. Having refreshed the Work with APPN Locations screen on RALYAS4C (by pressing F5), we can see the HPR session to RALYAS4A.
Work with APPN Locations System: Type options, press Enter. 5=Work with sessions 8=Work with RTP connections 12=Work with configuration status -------Remote------Location Network Name ID APPN216A RALYAS4A USIBMRA USIBMRA -------Local-------Location Network Name ID RALYAS4C RALYAS4C USIBMRA USIBMRA RALYAS4C
Opt
Controller APPN216A
Number of Sessions 2 1
F9=Retrieve
F12=Cancel
We can also refresh the RALYAS4A Work with APPN Locations screen.
398
Work with APPN Locations System: Type options, press Enter. 5=Work with sessions 8=Work with RTP connections 12=Work with configuration status -------Remote------Location Network Name ID APPN216B RALYAS4C USIBMRA USIBMRA -------Local-------Location Network Name ID RALYAS4A RALYAS4A USIBMRA USIBMRA RALYAS4A
Opt
Controller APPN216B
Number of Sessions 2 1
F9=Retrieve
F12=Cancel
To see the RTP connections on RALYAS4C, we entered the command WRKAPPNSTS again but this time selected option 2 to Work with RTP connections.
Work with RTP Connections System: Type options, press Enter. 5=Work with sessions 8=Work with APPN locations 9=Path switch 10=End connection 12=Work with configuration status ... RALYAS4C
Opt
Controller APPN216A
----RTP Partner----Control Network Point ID RALYAS4A USIBMRA
TCID 000020
Class of Service #CONNECT
F9=Retrieve F12=Cancel F23=More options
Figure 366. RALYAS4C Work with RTP Connections
To see the RTP connections on RALYAS4A, we entered the command WRKAPPNSTS again but this time selected option 2 to Work with RTP connections.
399
Work with RTP Connections System: Type options, press Enter. 5=Work with sessions 8=Work with APPN locations 9=Path switch 10=End connection 12=Work with configuration status ... RALYAS4A
Opt
Controller APPN216B
----RTP Partner----Control Network Point ID RALYAS4C USIBMRA
TCID 000020
Class of Service #CONNECT
F9=Retrieve F12=Cancel F23=More options
Figure 367. RALYAS4A Work with RTP Connections
The following screens were captured at the 2216A router with the pass-through session between RALYAS4A and RALYAS4C still active. In Figure 368, the list rtp_connections command displays the APPN RTP connections for which 2216A is a partner.
* t 5 CGW Operator Console +p appn APPN GWCON APPN >list rtp_connections RTP CONNECTION TABLE: TCID CP Name
ISR
APPC
Pathswitch
Alive
COS TPF
TG Numbe
================================================================================ 1E5DB30 1E73168 1E5F1D8 APPN > USIBMRA.APPN216B USIBMRA.APPN216B USIBMRA.APPN216B 0 0 0 1 1 0 180 180 0 180 180 180 CPSVCMG CPSVCMG RSETUP 21 21 21
Figure 368. 2210A RTP Connections
In Figure 369, the list isr_sessions command displays the APPN ISR sessions that are passing through 2216A.
APPN >list isr sessions Adjacent CP Name TG Number ISR Sessions =============================================== USIBMRA.RALYAS4C 1 0 APPN >
400
Figure 369 shows the ISR session for the pass-through session that was active between RALYAS4A and RALYAS4C.

STRTCPIFC INTNETADR( 1 0 . 1 . 1 . 2 )
To start the token-ring TCP/IP interface on RALYAS4A, we used the following command:
Interface not started You will receive this message if the TCP/IP support is not started on the AS/400. You can start TCP/IP on the system with the STRTCP command.
Starting a TCP/IP interface creates a *NET controller and a *NET device description under the relevant line description. We used the WRKCFGSTS CFGTYPE(*NWS) CFGD(FSIOP) command on RALYAS4C to verify this.
RALYAS4C 13:49:33
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FSIOP TOKENRING APPN216A APPN216A TOKENNET TOKENTCP Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE -------------Job--------------
QTCPIP
QTCP
068975
F23=More options
F24=More keys
Figure 370. RALYAS4C Work with Configuration Status. TCP/IP Configuration.
401
We checked the status of the RALYAS4C4C TCP/IP interfaces with the NETSTAT
*IFC command.
Work with TCP/IP Interface Status System: Type options, press Enter. 5=Display details 8=Display associated routes 9=Start 10=End 12=Work with configuration status 14=Display multicast groups Internet Address 10.1.1.2 127.0.0.1 Network Address 10.1.1.0 127.0.0.0 Line Description TOKENRING *LOOPBACK Interface Status Active Active RALYAS4C
Opt
Bottom F12=Cancel
Figure 371. RALYAS4C Work with TCP/IP Interface Status
We used the WRKCFGSTS CFGTYPE(*NWS) CFGD(IPCSBASE) command on RALYAS4A to verify the status of the configuration on this system.
RALYAS4A 09:58:07
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description IPCSBASE TOKENRING APPN216B APPN216B TOKENNET TOKENTCP Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE -------------Job--------------
QTCPIP
QTCP
069747
F23=More options
F24=More keys
Figure 372. RALYAS4A Work with Configuration Status. TCP/IP Configuration.
402
We checked the status of the RALYAS4A TCP/IP interfaces with the NETSTAT *IFC command.
Work with TCP/IP Interface Status System: Type options, press Enter. 5=Display details 8=Display associated routes 9=Start 10=End 12=Work with configuration status 14=Display multicast groups Internet Address 10.1.3.150 127.0.0.1 Network Address 10.1.3.0 127.0.0.0 Line Description TOKENRING *LOOPBACK Interface Status Active Active RALYAS4A
Opt
Bottom F12=Cancel
Figure 373. RALYAS4A Work with TCP/IP Interface Status
We checked the status of the RALYAS4C TCP/IP routes with the NETSTAT *RTE command.
Display TCP/IP Route Information System: Type options, press Enter. 5=Display details Route Destination 10.1.1.0 10.1.3.0 10.1.2.0 127.0.0.0 224.0.0.0 Subnet Mask 255.255.255.0 255.255.255.0 255.255.255.0 255.0.0.0 240.0.0.0 Next Hop *DIRECT 10.1.1.1 10.1.1.1 *DIRECT *DIRECT Route Available *YES *YES 1 *YES 2 *YES *YES RALYAS4C
Opt
F3=Exit F5=Refresh F11=Display route type
F6=Print list F12=Cancel
F9=Command line F13=Sort by column
F24=More keys
403
Display TCP/IP Route Information System: Type options, press Enter. 5=Display details Route Destination 10.1.1.0 10.1.3.0 10.1.2.0 127.0.0.0 224.0.0.0 Type of Service *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL Route MTU 1989 1989 1989 576 1989 Route Type *DIRECT *SUBNET *SUBNET *DIRECT *DIRECT Route Source *CFG *RIP 1 *RIP 2 *CFG *CFG RALYAS4C
Opt
F3=Exit F5=Refresh F11=Display route type
F6=Print list F12=Cancel
F9=Command line F13=Sort by column
F24=More keys Bottom
F17=Top
F18=Bottom
F24=More keys
1 10.1.3.0 2 10.1.2.0
This network is learned by RIP received from 2216A at 10.1.1.1 This network is learned by RIP received from 2216A at 10.1.1.1
We checked the status of the RALYAS4A TCP/IP routes with the NETSTAT *RTE command.
Display TCP/IP Route Information System: Type options, press Enter. 5=Display details Route Destination 10.1.3.0 10.1.2.0 10.1.1.0 127.0.0.0 224.0.0.0 Subnet Mask 255.255.255.0 255.255.255.0 255.255.255.0 255.0.0.0 240.0.0.0 Next Hop *DIRECT 10.1.3.1 10.1.3.1 *DIRECT *DIRECT Route Available *YES *YES 1 *YES 2 *YES *YES RALYAS4A
Opt
404
Display TCP/IP Route Information System: Type options, press Enter. 5=Display details Route Destination 10.1.3.0 10.1.2.0 10.1.1.0 127.0.0.0 224.0.0.0 *DFTROUTE Type of Service *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL *NORMAL Route MTU 1989 1989 1989 576 1989 576 Route Type *DIRECT *SUBNET *SUBNET *DIRECT *DIRECT *DFTROUTE Route Source *CFG *RIP 1 *RIP 2 *CFG *CFG *CFG RALYAS4A
Opt
F11=Display next hop F18=Bottom
1 10.1.2.0 2 10.1.1.0
This network is learned by RIP received from 2216B at 10.1.3.1 This network is learned by RIP received from 2216B at 10.1.3.1
D:\>ftp 10.1.3.121 IBM TCP/IP for OS/2 - FTP Client ver 08:36:08 on Jul 22 1996 Connected to 10.1.3.121. 220-QTCP at 10.1.3.121. 220 Connection will close if idle more than 5 minutes. Name (10.1.3.121): mick 331 Enter password. Password: ....... 230 MICK logged on. ftp>
Figure 378. Using FTP to Verify the Connection Status

First we must start IPX. On RALYAS4C we used the following command to do this:
405
We started IPX on RALYAS4A using the following command:
Starting an IPX circuit creates a *NET controller and a *NET device description under the relevant line description. For the network server interface on RALYAS4C we used the WRKCFGSTS CFGTYPE(*NWS) CFGD(FSIOP) command to verify this.
RALYAS4C 13:13:12
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FSIOP TOKENRING APPN216A APPN216A TOKENNET TOKENTCP TOKENIPX Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE -------------Job--------------
QTCPIP QIPX
QTCP QSYS
068975 068106
F23=More options
F24=More keys
Figure 379. RALYAS4C Work with Configuration Status. IPX Configuration.
For the network server interface on RALYAS4A we used the WRKCFGSTS CFGTYPE(*NWS) CFGD(IPCSBASE) command to verify the status of the configuration on this system.
406
RALYAS4A 10:18:17
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description IPCSBASE TOKENRING APPN216B APPN216B TOKENNET TOKENTCP TOKENIPX Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE -------------Job--------------
QTCPIP QIPX
QTCP QSYS
001722 001896 Bottom
F23=More options
F24=More keys
Figure 380. RALYAS4A Work with Configuration Status. IPX Configuration.
We then used the WRKIPXCCT command on RALYAS4C to verify the status of the IPX circuits.
Work with IPX Circuits System: Type options, press Enter. 1=Add 2=Change 4=Remove 8=Display associated routes Circuit Name TOKENRING 5=Display 9=Start Line Description TOKENRING RALYAS4C
7=Display associated services 10=End Line Type *TRLAN Circuit Status Active
Opt
F3=Exit
F5=Refresh
F6=Print list
F12=Cancel
F17=Top
F18=Bottom
Figure 381. RALYAS4C Work with IPX Circuits
The WRKIPXSTS command option 3 can be used on RALYAS4C to verify the IPX service information.
407
Type options, press Enter. 5=Display details Service name MICKS_SERVER MICKS_DIR________> MICKS_SERVER Service Type *FILESVR 026B 026B Remote Network 305C227F6 305C227F6 305C227F6 Hops to Service 1 1 1 Service Source *SAP *SAP *SAP
Opt
F3=Exit
F5=Refresh
F6=Print list
F12=Cancel
F17=Top
F18=Bottom
Figure 382. RALYAS4C Work with IPX Services Information
In Figure 382 we can see the IPX service information from servers on the network. We then used the WRKIPXSTS command with option 2 on RALYAS4C to verify the status of the IPX routes.
Display IPX Route Information System: Number of routes . . . . . . . . . . . . . . : 5 RALYAS4C
Type options, press Enter. 5=Display details Remote Network 00000009 00000BBB 0002210A 96AD0D47 FE755385 Number of Hops 0 1 2 0 3 Number of Ticks 1 3 4 1 5 Next Hop Node Address *NONE 400022160000 400022160000 000000000001 400022160000 Route Source *CCT *RIP *RIP *LOCAL *RIP
Opt
Bottom F3=Exit F5=Refresh F6=Print list F12=Cancel F17=Top F18=Bottom
Figure 383. RALYAS4C Work with IPX Route Information
In Figure 383 we can see the IPX routes that have been discovered by RALYAS4C from the network.
408
We can use IPXPING to verify an IPX connection between RALYAS4C and RALYAS4A by entering the following command at RALYAS4C:
IPXPING RMTNETNBR(FE755385) RMTNDEADR(400000000150)

FE755385 is the randomly generated internal IPX number of RALYAS4A and 400000000150 is the token-ring adapter number.
Command Entry
RALYAS4C Request level: 7 connection connection connection connection connection
Previous commands and messages: Connection verification 1 took .043 seconds. 1 successful verifications. Connection verification 2 took .042 seconds. 2 successful verifications. Connection verification 3 took .042 seconds. 3 successful verifications. Connection verification 4 took .042 seconds. 4 successful verifications. Connection verification 5 took .042 seconds. 5 successful verifications. Round-trip (in milliseconds) min/avg/max = 42/42/43 Connection verification statistics: 5 of 5 successful (100 Type command, press Enter. ===>
%). Bottom
F3=Exit F4=Prompt F11=Display full F3=Exit F5=Refresh
F9=Retrieve F10=Include detailed messages F12=Cancel F13=Information Assistant F24=More keys F6=Print list F12=Cancel F17=Top F18=Bottom
Figure 384. IPXPING f r o m RALYAS4C to RALYAS4A
We can now start a Novell client.
409
TOKENCS-DOS-200: Inserting into the ring. Please Wait. Int 2, Port A20, Mem D0000, Mem D8000, Node Address 8005AE475B9 M Max Frame 4210 bytes, Line Speed 16 Mbps Board 1, Frame TOKEN-RING, MSB Mode NetWare IPX/SPX Protocol v3.01 (941031) (C) Copyright 1990-1994 Novell, Inc. All Rights Reserved. IPX RETRY COUNT 50 Bound to logical board 1 (TOKENCS) : Protocol ID E0 NetWare Source Routing Driver v2.21 (940315) (C) Copyright 1993 Novell Inc. All Rights Reserved. ROUTE-DOS-200: Current ROUTE.com parameters for Board #1 are: DEFault Node (Unknown) Addresses are sent SINGLE ROUTE Broadcast. Broadcast (FFFF FFFF FFFF) Addresses are sent SINGLE ROUTE Broadcast. Multicast (C000 xxxx xxxx) Addresses are sent SINGLE ROUTE Broadcast. Maximum HOPS = 7 Bridges; NODES = 16; Aging TIME = 10 Seconds. This Ring Only (TRO) Count = 0; Extra Transmit (XTX) Count = 2.
VLM.EXE - NetWare virtual loadable module manager (C) Copyright 1994 Novell, Inc. All Rights Reserved. Patent pending.
v1.20 (941108)
410
Chapter 13. APPN/HPR Encapsulation in TCP/IP

In this scenario we build a router network that uses IBM 2210/2216 Enterprise Extender. In previous scenarios we have looked at the transport of SNA/APPN across the router network natively (using the router s native APPN or APPN/HPR support) or by using data link switching. In this scenario we look at how we can use Enterprise Extender to do the same. Enterprise Extender achieves the transport of APPN/HPR across the router network by encapsulating the APPN/HPR packets in IP. The objectives of this scenario are as follows:
To connect a remote site LAN to a central site LAN for the transport of APPN/HPR. To connect a remote IBM 5494 to the central site AS/400. To configure HPR over IP for the transport of SNA/APPN. To connect an AS/400 at the central site to an IBM 2216 using a LAN link. To connect an AS/400 at the remote site to an IBM 2210 using a LAN link. To connect an IBM 5494 to an IBM 2210 using an SDLC WAN link.
In the first section of this chapter we look at a network overview and the hardware and software involved. Following that we review the APPN network. We then look at the router definitions required. In the last section we verify the APPN connectivity.
Figure 386. Enterprise Extender - HPR encapsulated in IP
411
IP, IPX and NetBIOS While we only show the configuration for APPN/HPR in this scenario, Enterprise Extender can be incorporated with methods shown in previous scenarios such that the network becomes a multiprotocol network.
Routers IBM 2216 Nways Multiaccess Connector, with MAS V2R2. IBM 2210 Model 14T, with MRS V2R2 and 32 MB of memory.
PPP WAN link between the IBM 2216 and the IBM2210 The speed of the connection is 64 Kbps. We used a modem eliminator with V.35 interfaces.
Two AS/400 systems With OS/400 V4R2.
412

In our multiprotocol router network we defined HPR over IP to support the SNA traffic between the remote 5494/LAN and the central AS/400. The IBM 2216, IBM 2210 and the AS/400s are configured as APPN network nodes. The 5494 is a LEN node. Figure 387 shows the APPN network including the network ID and CP names.
Figure 387. Enterprise Extender. APPN Network.

In this section we show the AS/400 APPN network definitions. For this scenario we created a token-ring line description. AS/400 Network Attributes: The AS/400 APPN node type, Network ID and CP name are defined in the system network attributes. To display the network attributes for RALYAS4C, use the command DSPNETA.
413
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
: : : : : : : : : : : :
RALYAS4C
*ANY More...
From Figure 388 take note of the Local network ID and Local control point name. We enabled the HPR tower function on RALYAS4C. The parameter for this is on the last screen of the network attributes as shown in Figure 389.
Display Network Attributes System: Maximum hop count . . . . . . . . DDM request access . . . . . . . . Client request access . . . . . . Default ISDN network type . . . . Default ISDN connection list . . . Allow AnyNet support . . . . . . . Network server domain . . . . . . Allow APPN virtual support . . . . Allow HPR transport tower support Virtual controller autocreate APPC HPR path switch timers: Network priority . . . . . . . . High priority . . . . . . . . . Medium priority . . . . . . . . Low priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . device limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : : : : : 16 *OBJAUT *OBJAUT QDCCNNLANY *YES S100CBDM *NO *YES 100 1 2 4 8 Bottom Press Enter to continue. F3=Exit F12=Cancel RALYAS4C
414

The important parameters for the network server are: Network server description (NWSD) The unique name for this network server description. Resource name (RSRCNAME) Use the Work with Hardware Resource (WRKHDWSC) command with *CMN to find the correct resource name for the FSIOP. Network server type (TYPE) We used the FSIOP only as a LAN adapter. Start NetBIOS (STRNTB) We didn t use NetBIOS support.
The important parameters in the token-ring line description are: Line description (LIND) The unique name for this line description. Resource name (RSRCNAME) In this scenario we are using an FSIOP to connect to the network and therefore specify *NWSD as the resource name. Network server description (NWS) Specifies the network server to which this line is attached and the port to use. Line speed (LINESPEED) Specifies the line speed in bits per second (bps). Local adapter address (ADPTADR) Specifies the local system s token-ring adapter address. Note: The APPC controller, APPC device, remote workstation controller and the remote workstation device descriptions are created automatically on a token-ring connection when the link between the 2210 and AS/400 becomes active providing the QAUTOCFG and QAUTORMT system values are set to 1 (on) and the AUTOCRTCTL parameter in the token-ring line description is set to *YES. Alternatively, we could have created the APPC controller description for the 2216 using the following command:
CRTCTLAPPC CTLD(HPR2216) LINKTYPE(*LAN) SWTLINLST(TOKENRING) RMTCPNAME(HPR2216) ADPTADR(40002216000A) NODETYPE(*NETNODE) TEXT( APPC Controller for 2216 )
415
AS/400 APPN Remote Location Configuration List An entry might be needed in the APPN Remote Locations Configuration List, on RALYAS4C, for location RAL5494A. You can add this entry with this command:
ADDCFGLE TYPE(*APPNRMT) APPNRMTE((RAL5494A *NETATR *NETATR HPR2210 *NETATR))

The AS/400 APPN node type, Network ID and CP name are defined in the system network attributes. To display the network attributes for RALYAS4A, use the command DSPNETA.
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
: : : : : : : : : : : :
System: RALYAS4A USIBMRA RALYAS4A RALYAS4A BLANK *NETNODE *NONE *NONE 200 128 *LCLNETID
RALYAS4A
*ANY More...
From Figure 390 take note of the Local network ID and Local control point name. We enabled the HPR tower function on RALYAS4C. The parameter for this is on the last screen of the network attributes as shown in Figure 391 on page 417.
416
Display Network Attributes System: Maximum hop count . . . . . . . . DDM request access . . . . . . . . Client request access . . . . . . Default ISDN network type . . . . Default ISDN connection list . . . Allow AnyNet support . . . . . . . Network server domain . . . . . . Allow APPN virtual support . . . . Allow HPR transport tower support Virtual controller autocreate APPC HPR path switch timers: Network priority . . . . . . . . High priority . . . . . . . . . Medium priority . . . . . . . . Low priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . device limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : : : : : 16 *OBJAUT *OBJAUT QDCCNNLANY *YES S100CBDM *NO *YES 100 1 2 4 8 Bottom Press Enter to continue. F3=Exit F12=Cancel RALYAS4A
Token-Ring Line Description: For token-ring, the physical connection between an AS/400 and a network is defined using a line description . The token-ring adapter that we used in this scenario was associated with an Integrated PC Server (IPCS). We therefore first created a network server description then the actual line description.

The important parameters for the network server are: Network server description (NWSD) The unique name for this network server description. Resource name (RSRCNAME) Use the Work with Hardware Resource (WRKHDWSC) command with *CMN to find the correct resource name for the IPCS. Network server type (TYPE) We used the IPCS only as a LAN adapter. Start NetBIOS (STRNTB) We didn t use NetBIOS support.
CRTLINTRN LIND(TOKENRING) RSRCNAME(*NWSD) NWS(IPCSBASE 1) LINESPEED(16M) MAXFRAME(1994) ADPTADR(400000000150) TEXT( Token Ring Line on IPCSBASE )
417
AUTOCRTCTL(*YES)
The important parameters in the token-ring line description are: Line description (LIND) The unique name for this line description. Resource name (RSRCNAME) In this scenario we are using an IPCS to connect to the network and therefore specify *NWSD as the resource name. Network server description (NWS) Specifies the network server to which this line is attached and the port to use. Line speed (LINESPEED) Specifies the line speed in bits per second (bps). Local adapter address (ADPTADR) Specifies the local system s token-ring adapter address. Note: The APPC controller and APPC device descriptions are autocreated when the link between the AS/400 and 2216 becomes active provided that the QAUTOCFG system value is set to 1 (on) and the AUTOCRTCTL parameter in the token-ring line description is set to *YES. Alternatively, we could have created the APPC controller description for the 2210 using the following command:
CRTCTLAPPC CTLD(HPR2210) LINKTYPE(*LAN) SWTLINLST(TOKENRING) RMTCPNAME(HPR2210) ADPTADR(400022100014) NODETYPE(*NETNODE) TEXT( APPC Controller for 2210A )

We defined the IBM 5494 remote workstation controller to communicate with AS/400 RALYAS4C. What about the 5394 If you are using the 5394 with 8Q0775 microcode diskette the configuration parameters and screens are the same as for the 5494.
418
0/ 1/ 2/ 3/
0 1 2 3 4 5 6 ---------------------------------------------------------00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AA 0 1- 00 - -
2- 10
3-
DD0 1 1 0 0 0 0
0 8060 P- -
111519-
H1:1H1:5-
H2:1H2:5-
H3:1H3:5-
H4:1H4:5-
419
Table 20 (Page 2 of 2). IBM 5494 Configuration Parameters Field /Subfield 3/3 3/4 3/5 3/6 3/7 8 P 11 12 13 14 15 16 17 18 19 20 21 22 23 H1:1 H1:2 H1:3 H1:4 H1:5 H1:7 H1:8 H1:9 Note: Field Description Connection Type Data Encoding Connection Method Send Leading Pad Local Loopback Support V.25 bis Parameters Configuration Printer Network ID of 5494 LU Name of 5494 CP Name of 5494 Mode Name 5494 MAC Address Retry Parameters 5494 Serial Number 5494 ID Number 5494 ID Number Primary AS/400 System Concurrent Host Attachment Concurrent Host Attachment Printer Timeout Synchronize 5494 Date and Time with Primary AS/400 AS/400 LU Name AS/400 Network ID 5494 Network ID Mode Name AS/400 MAC Address Token-Ring SAP TR Max Out TR Max In 04 2 1 RALYAS4C USIBMRA USIBMRA QRMTWSC 010 06 USIBMRA RAL5494A RAL5494A QRMTWSC Same as AS/400 Value Selected 1 0 0 0 0 060 Value Description Point-to-point NRZI
DTR 1 No 1 No 1
1 1 1
420

In this section we show the IBM 2216 and IBM 2210 router configurations that were used in this scenario.

13.3.2 Starting the 2216 Configuration

We selected:

421


A token-ring interface A PPP serial interface to the 2210
We selected:

422
423

We also configured an internal IP address. Configuring the Internal IP Address Select General from the IP folder.
We Entered an Internal address of 10.1.1.1. Note The internal IP address is used for HPR over IP. This IP address will later be defined as an HPR over IP partner on the 2210. By convention, we normally use the LAN interface IP address as the internal IP address.
424
We Entered:

425
We Entered:

426
427

We selected:

Enable APPN network node . Set the Network ID to USIBMRA . Set the Control point name to HPR2216 .
428
We selected:

Define Port for interface 0 . Used the scroll down bar to display the Pseudo HPR over IP interface and selected Define port for this interface. Port Configuration
429
HPR over IP APPN Configuration: We used HPR over IP to connect to the 2210. Select Link Stations against the Pseudo HPR over IP interface.
Figure 403. Configuring the HPR over IP APPN Interface o n the 2216
From General-1 we set the Link station name to HPR2210 .
430
Select General-2 to enter the partner IP address and adjacent node type.
Figure 404. Configuring the HPR over IP APPN Interface o n the 2216 Continued

Adjacent node type of APPN network node . An IP address of adjacent node of 10.1.3.1. Pressed Add . Note
The IP address of adjacent node is the HPR over IP partner router s internal IP address.
431
Token-ring interface 0 APPN Configuration: We used token-ring interface 0 to connect to RALYAS4C. Select Link Stations against token-ring interface 0.
432
A MAC address for adjacent node of 400000000000 (see Token-Ring Line Description on page 414). Adjacent node type of APPN network node . Pressed Add .
433

We selected:

434


435


A token-ring interface A PPP interface to the IBM 2216 An SDLC interface to the IBM 5494
We selected:

436

437

438

We also added an internal IP address. Configuring the Internal IP Address Select General from the IP folder.
We Entered an Internal address of 10.1.3.1. Note The internal IP address is used for HPR over IP. This IP address was defined as an HPR over IP partner on the 2216. By convention, we normally use the LAN interface IP address as the internal IP address.
439
We entered:

440
Figure 414. IP Configuration for the 2210 PPP Interface
We entered:

441
442

We selected:

Enable APPN network node . Set the Network ID to USIBMRA . Set the Control point name to HPR2210 .
443
We selected:

Define Port for interface 0 . Define Port for interface 2 . Used the scroll down bar to display the Pseudo HPR over IP interface and selected Define port for this interface. Port Configuration
444
HPR over IP APPN Configuration: We used HPR over IP to connect to the 2210. Select Link Stations against the Pseudo HPR over IP interface .
Figure 418. Configuring the HPR over IP APPN Interface o n the 2216
From General-1 we set the Link station name to HPR2216 .
445
Select General-2 to enter the partner IP address and adjacent node type.
Figure 419. Configuring the HPR over IP APPN Interface o n the 2216 Continued

Adjacent node type of APPN network node . An IP address of adjacent node of 10.1.1.1. Pressed Add . IP address of adjacent node
The IP address of adjacent node is the HPR over IP partner router s internal IP address.
446
From General-1 we set the Link station name to RALYAS4A .
447
Select General-2 to enter a MAC address and adjacent node type.
A MAC address for adjacent node of 400000000150 (see Token-Ring Line Description on page 417). Adjacent node type of APPN network node . Pressed Add .
448
From General-1 we:

Set the Link station name to RAL5494A . De-selected Allow CP-CP sessions on this link.
449

450

We selected:

451

Before we can start the APPN protocol on the AS/400, we have to vary on (activate) the network servers and the token-ring line descriptions on RALYAS4C and RALYAS4A. To vary on the network server on RALYAS4C, we used the following command:




VRYCFG CFGOBJ(HPR2216) CFGTYPE(*CTL) STATUS(*ON)

To start the APPN session between RALYAS4A and the 2210, we used the following command to vary on (activate) the APPC controller description:
VRYCFG CFGOBJ(HPR2210) CFGTYPE(*CTL) STATUS(*ON)

The APPN device descriptions for the 2216 and 2210 CP-CP sessions will be autocreated by the AS/400s when the APPN sessions become active. We can see the status of the RALYAS4C network server and associated configuration objects using the command:
452
RALYAS4C 16:20:01
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FSIOP TOKENRING HPR2216 HPR2216 Status ACTIVE ACTIVE ACTIVE ACTIVE -------------Job--------------
F23=More options
F24=More keys

Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description IPCSBASE TOKENRING HPR2210 HPR2210 Status ACTIVE ACTIVE ACTIVE ACTIVE -------------Job--------------
F23=More options
F24=More keys
5494 APPC controller Note that there is no APPC controller for the 5494 in this scenario. The 5494 session is controlled and owned by HPR2210.
453

F23=More options
F24=More keys
Figure 427. RALYAS4C Work with Configuration Status. Remote Workstation Controller Configuration.
We can now start an HPR session between RALYAS4A and RALYAS4C, for example, by starting a pass-through session by entering the command STRPASTHR RALYAS4C at RALYAS4A. Having established the pasthru session, we can see the status of the RALYAS4C AS/400 APPN information using the command WRKAPPNSTS.
454
Work with APPN Locations System: Type options, press Enter. 5=Work with sessions 8=Work with RTP connections 12=Work with configuration status -------Remote------Location Network Name ID HPR2216 RALYAS4A RAL5494A USIBMRA USIBMRA USIBMRA -------Local-------Location Network Name ID RALYAS4C RALYAS4C RALYAS4C USIBMRA USIBMRA USIBMRA RALYAS4C
Opt
Controller HPR2216
Number of Sessions 2 3 2 1 2 3
F9=Retrieve
F12=Cancel
1 2 3
CP sessions with the 2216 (HPR2216) APPN sessions with RALYAS4A via the controller (PU) HPR2216 APPN session with the 5494 (RAL5494A) via the controller (PU) HPR2216
455
Work with APPN Locations System: Type options, press Enter. 5=Work with sessions 8=Work with RTP connections 12=Work with configuration status -------Remote------Location Network Name ID HPR2210 RALYAS4C USIBMRA USIBMRA -------Local-------Location Network Name ID RALYAS4A RALYAS4A USIBMRA USIBMRA RALYAS4A
Opt
Controller HPR2210
Number of Sessions 2 3 1 2 Bottom
F9=Retrieve
F12=Cancel
1 2
CP sessions with the 2210 (HPR2210) APPN sessions with RALYAS4C via the controller (PU) HPR2210
To see the RTP connections on RALYAS4C, we entered the command WRKAPPNSTS again but this time selected option 2 to Work with RTP connections.
Work with RTP Connections System: RALYAS4C Type options, press Enter. 5=Work with sessions 8=Work with APPN locations 9=Path switch 10=End connection 12=Work with configuration status ... ----RTP Partner----Control Network Class of Number of Opt Controller Point ID TCID Service Sessions HPR2216 HPR2210 USIBMRA 000058 #CONNECT 2 1 RALYAS4A USIBMRA 000038 #CONNECT 3 2
Figure 431. RALYAS4C Work with RTP Connections
In Figure 431 we can see the following RTP connections:
1 One with the 2210 (HPR2210) via the controller (PU) HPR2216 2 One with RALYAS4A also via the controller (PU) HPR2216
456
The following screens were captured at the 2210 router with the pass-through session between RALYAS4A and RALYAS4C still active. In Figure 432, the list link_information command displays the status of the 2210 APPN link stations.
*t 5 +p appn APPN GWCON APPN >list link_information Name Port Name Intf Adj CP Name Type HPR State ========================================================================= RALYAS4C TR000 0 USIBMRA.RALYAS4C NN ACTIVE ACT_LS HPR2210 IP255 8 USIBMRA.HPR2210 NN ACTIVE ACT_LS APPN >
Figure 432. 2210 Link Stations
In Figure 433, the list cp-cp sessions command displays the status of the 2210 APPN CP-CP sessions.
APPN >list cp-cp sessions CP Name Type Status Connwinner ID Conloser ID ======================================================================== USIBMRA.RALYAS4C NN Active 35813FF1 35813FF3 USIBMRA.HPR2210 NN Active 35813FFB 35813FFD APPN >
457
458
Chapter 14. APPN Network Extension

In this scenario we build a router network that uses IBM 2210/2216 Branch Extender. Branch Extender provides a mechanism that allows an APPN network to be extended (nodes added) without having to add network nodes to the network. It does this by allowing the added node (the Branch Extender node) to see the node to which it is attached as a network node (and hence a node with which it can exchange APPN information - APPN topology information) while the node to which it is attached sees the added node (the Branch Extender node) as an end node (and hence not an extension to the network). The objectives of this scenario are as follows:
To interconnect two AS/400s where one AS/400 is downstream of the Branch Extender router. To connect a remote IBM 5494 to the central site AS/400. To configure Branch Extender for the transport of SNA/APPN. To connect an AS/400 at the central site to an IBM 2216 using a LAN link. To connect an AS/400 at a remote site to an IBM 2210 using a LAN link. To connect an IBM 5494 to an IBM 2210 using an SDLC WAN link.
In the first section of this chapter we look at a network overview and the hardware and software involved. Following that we review the APPN network. We then look at the router definitions required. In the last section we verify the APPN connectivity.
Figure 434. Branch Extender - Extending an APPN Network
RALYAS4A is downstream of an end node connection (2216 to 2210A) but still able to reach RALYAS4C via this connection.
459
IP, IPX and NetBIOS While we only show the configuration for APPN/HPR in this scenario, Branch Extender can be incorporated with methods shown in previous scenarios such that the network becomes a multiprotocol network.
Routers IBM 2216 Nways Multiaccess Connector, with MAS V2R2. IBM 2210, Model 14T, with MRS V2R2 and 32 MB of memory. IBM 2210, Model 14E, with MRS V2R2 and 32 MB of memory.
WAN links between the 2210s and 2216 The speed of the connection is 64 Kbps. We used a modem eliminator with V.35 interfaces.
WAN SDLC link between the IBM 2210 and the 5494 The speed of this connection is 19.2 Kbps. We used a modem 2210 DCE cable and a normal V.24 5494 cable.
LAN multi-access units/hub: IBM 8228 to build the token-ring LAN segment. IBM 8271 to build the Ethernet LAN segment.
Two AS/400 systems With OS/400 V4R2.
460

In our multiprotocol router network we defined SNA/APPN to support SNA traffic between the remote 5494, AS/400 and LANs and the central AS/400. The IBM 2216, IBM 2210s and the central AS/400 are configured as APPN network nodes. The remote AS/400 is configured as an end node and the 5494 is a LEN node. Figure 435 shows the APPN network including the network ID and CP names.
Figure 435. Branch Extender. APPN Configuration.
RALYAS4A is downstream of an end node connection but still able to connect to RALYAS4C.

In this section we show the AS/400 APPN network definitions. For this scenario we created a token-ring line description. AS/400 Network Attributes: The AS/400 APPN node type, network ID and CP name are defined in the system network attributes. To display the network attributes for RALYAS4C, use the command DSPNETA.
461
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
: : : : : : : : : : : :
RALYAS4C
*ANY More...
From Figure 436 take note of the local network ID and local control point name. We disabled the HPR tower function on RALYAS4C. The parameter for this is shown on the last screen of the network attributes as shown in Figure 437.
Display Network Attributes System: Maximum hop count . . . . . . . . DDM request access . . . . . . . . Client request access . . . . . . Default ISDN network type . . . . Default ISDN connection list . . . Allow AnyNet support . . . . . . . Network server domain . . . . . . Allow APPN virtual support . . . . Allow HPR transport tower support Virtual controller autocreate APPC HPR path switch timers: Network priority . . . . . . . . High priority . . . . . . . . . Medium priority . . . . . . . . Low priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . device limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : : : : : 16 *OBJAUT *OBJAUT QDCCNNLANY *YES S100CBDM *NO *NO 100 1 2 4 8 Bottom Press Enter to continue. F3=Exit F12=Cancel RALYAS4C
If necessary, use the following command to disable HPR:
462
CRTNWSD NWSD(FSIOP 1) RSRCNAME(CC04) TYPE(*BASE) STRNTB(*NO) TEXT( File Server IOP )

The important parameters for the network server are: Network server description (NWSD) The unique name for this network server description. Resource name (RSRCNAME) Use the Work with Hardware Resource (WRKHDWSC) command with *CMN to find the correct resource name for the FSIOP. Network server type (TYPE) We used the FSIOP only as a LAN adapter. Start NetBIOS (STRNTB) We didn t use NetBIOS support.
The important parameters in the token-ring line description are: Line description (LIND) The unique name for this line description. Resource name (RSRCNAME) In this scenario we are using an FSIOP to connect to the network and therefore specify *NWSD as the resource name. Network server description (NWS) Specifies the network server to which this line is attached and the port to use. Line speed (LINESPEED) Specifies the line speed in bits per second (bps). Local adapter address (ADPTADR) Specifies the local system s token-ring adapter address. Note: The APPC controller and APPC device descriptions and remote workstation controller and device are autocreated for a token-ring connection when the link between the AS/400 and 2216 becomes active provided that the QAUTOCFG and QAUTORMT system values are set to 1 (on) and the AUTOCRTCTL parameter in the token-ring line description is set to *YES. Alternatively, we could have created the APPC controller description for the 2216 using the following command:
CRTCTLAPPC CTLD(BX2216) LINKTYPE(*LAN) SWTLINLST(TOKENRING) RMTCPNAME(BX2216) ADPTADR(40002216000A) NODETYPE(*NETNODE) TEXT( APPC Controller for 2216 )
463
AS/400 APPN Remote Location Configuration List An entry might be needed in the APPN Remote Locations Configuration List, on RALYAS4C, for location RAL5494A. You can add this entry with this command:
ADDCFGLE TYPE(*APPNRMT) APPNRMTE((RAL5494A *NETATR *NETATR *NONE BX2216))

The AS/400 APPN node type, network ID and CP name are defined in the system network attributes. To display the network attributes for RALYAS4A, use the command DSPNETA.
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
: : : : : : : : : : : :
System: RALYAS4A USIBMRA RALYAS4A RALYAS4A BLANK *ENDNODE *NONE *NONE 200 128 *LCLNETID
RALYAS4A
*ANY More...
From Figure 438 take note of the Local network ID and Local control point name. We disabled the HPR tower function on RALYAS4C. The parameter for this is shown on the last screen of the network attributes as shown in Figure 439 on page 465.
464
Display Network Attributes System: Maximum hop count . . . . . . . . DDM request access . . . . . . . . Client request access . . . . . . Default ISDN network type . . . . Default ISDN connection list . . . Allow AnyNet support . . . . . . . Network server domain . . . . . . Allow APPN virtual support . . . . Allow HPR transport tower support Virtual controller autocreate APPC HPR path switch timers: Network priority . . . . . . . . High priority . . . . . . . . . Medium priority . . . . . . . . Low priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . device limit . . . . . . . . . . . . . . . . . . . . . . . . . . . . : : : : : : : : : : : : : : 16 *OBJAUT *OBJAUT QDCCNNLANY *YES S100CBDM *NO *NO 100 1 2 4 8 RALYAS4A
If necessary, use the following command to disable HPR:
Token-Ring Line Description: For token-ring, the physical connection between an AS/400 and a network is defined using a line description . The token-ring adapter that we used in this scenario was associated with a Integrated PC Server (IPCS). We therefore first created a network server description then the actual line description.

The important parameters for the network server are: Network server description (NWSD) The unique name for this network server description Resource name (RSRCNAME) Use the Work with Hardware Resource (WRKHDWSC) command with *CMN to find the correct resource name for the IPCS. Network server type (TYPE) We used the IPCS only as a LAN adapter. Start NetBIOS (STRNTB) We didn t use NetBIOS support.
CRTLINTRN LIND(TOKENRING) RSRCNAME(*NWSD) NWS(IPCSBASE 1) LINESPEED(16M) MAXFRAME(1994) ADPTADR(400000000150)

465
TEXT( Token Ring Line on IPCSBASE )
The important parameters in the token-ring line description are: Line description (LIND) The unique name for this line description. Resource name (RSRCNAME) In this scenario we are using an IPCS to connect to the network and therefore specify *NWSD as the resource name. Network server description (NWS) Specifies the network server to which this line is attached and the port to use. Line speed (LINESPEED) Specifies the line speed in bits per second (bps). Local adapter address (ADPTADR) Specifies the local system s token-ring adapter address. Note: The APPC controller and APPC device descriptions are autocreated on a token-ring connection when the link between the AS/400 and 2216 becomes active provided that the QAUTOCFG system value is set to 1 (on) and the AUTOCRTCTL parameter in the token-ring line description is set to *YES. Alternatively, we could have created the APPC controller description for the 2210 using the following command:
CRTCTLAPPC CTLD(BX2210T) LINKTYPE(*LAN) SWTLINLST(TOKENRING) RMTCPNAME(BX2210T) ADPTADR(400022100014) NODETYPE(*NETNODE) TEXT( APPC Controller for 2210T )
CALL QCMD If entered as shown, the command above will overflow the number of command entry lines made available. We can get extra lines by entering the command CALL QCMD.

We defined the IBM 5494 remote workstation controller to communicate with AS/400 RALYAS4C. What about the 5394 If you are using the 5394 with 8Q0775 microcode diskette the configuration parameters and screens are the same as for the 5494.
466
0/ 1/ 2/ 3/
0 1 2 3 4 5 6 ---------------------------------------------------------00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
AA 0 1- 00 - -
2- 10
3-
DD0 1 1 0 0 0 0
0 8060 P- -
111519-
H1:1H1:5-
H2:1H2:5-
H3:1H3:5-
H4:1H4:5-
467
Table 21 (Page 2 of 2). IBM 5494 Configuration Parameters Field /Subfield 3/3 3/4 3/5 3/6 3/7 8 P 11 12 13 14 15 16 17 18 19 20 21 22 23 H1:1 H1:2 H1:3 H1:4 H1:5 H1:7 H1:8 H1:9 Note: Field Description Connection Type Data Encoding Connection Method Send Leading Pad Local Loopback Support V.25 bis Parameters Configuration Printer Network ID of 5494 LU Name of 5494 CP Name of 5494 Mode Name 5494 MAC Address Retry Parameters 5494 Serial Number 5494 ID Number 5494 ID Number Primary AS/400 System Concurrent Host Attachment Concurrent Host Attachment Printer Timeout Synchronize 5494 Date and Time with Primary AS/400 AS/400 LU Name AS/400 Network ID 5494 Network ID Mode Name AS/400 MAC Address Token-Ring SAP TR Max Out TR Max In 04 2 1 RALYAS4C USIBMRA USIBMRA QRMTWSC 010 06 USIBMRA RAL5494A RAL5494A QRMTWSC Same as AS/400 Value Selected 1 0 0 0 0 060 Value Description Point-to-point NRZI
DTR 1 No 1 No 1
1 1 1
468
AS/400 APPN Remote Location Configuration List An entry might be needed in the APPN Remote Locations Configuration List for location RAL5494. You can add this entry using the following command:
ADDCFGLE TYPE(*APPNRMT) APPNRMTE((RAL5494A *NETATR *NETATR *NONE BX2210E))

469

In this section we show the IBM 2216 and IBM 2210 router configurations that were used in this scenario.

14.3.2 Starting the 2216 Configuration

We selected:

470


A token-ring interface A PPP serial interface to each of the 2210s
We selected:

471
Configuring the Serial PPP Interface 2: We used serial interface 2 to connect to the 2210A. Select Configure against serial interface 2.
Figure 444. Configuring the 2216 Serial Interface to 2210A
472
Configuring the Serial PPP Interface 3: We used serial interface 3 to connect to the 2210B. Use the scroll down bar to display Interface 3, then select Configure against interface 3.
473

We selected:

Enable APPN network node . Set the Network ID to USIBMRA . Set the Control point name to BX2216 .
474
We selected:

Define Port for interface 0 . Define Port for interface 2 . Used the scroll down bar to display interface 3 and selected Define port for this interface. Configure against interface 3 and de-selected HPR on this interface.
475
From General-1 we:

Set the Link station name to BX2210E. De-selected HPR supported .
476

477
Serial interface 2 APPN Port Configuration: We used the serial interface 2 to connect to 2210A. Select Configure against serial interface 2.
Figure 450. Port Configuration for 2216 Interface 2
From General we de-selected HPR .
478
Serial interface 2 APPN Link Station Configuration: We used the serial interface 2 to connect to 2210A. Select Link Stations against serial interface 2.
From General-1 we:

Set the Link station name to BX2210T . De-selected HPR supported .
479

Adjacent node type APPN end node . Pressed Add . Note Note that the configuration of 2210A from the 2216 is as an end node.
480
Token-Ring interface 0 APPN Port Configuration: We used token-ring interface 0 to connect to RALYAS4C. Select Configure against token-ring interface 0.
Figure 453. Port Configuration for 2216 Interface 0
481
Token-Ring interface 0 APPN Link Station Configuration: We used token-ring interface 0 to connect to RALYAS4C. Select Link Stations against token-ring interface 0.
From General-1 we:

Set the Link station name to RALYAS4C . De-selected HPR supported .
482
A MAC address of adjacent node of 400000000000 (see Token-Ring Line Description on page 462). Adjacent node type of APPN network node . Pressed Add .
483

We selected:

Save configuration as... A Configuration name of BX2216 in the config.cdb database. OK . Selected Configure once more. Create router configuration... A configuration file name of BX2216.CFG .
484
14.4 2210A Configuration


485


A token-ring interface A PPP interface to the IBM 2216
We selected:

486

487

We selected:

Enable APPN network node . Set the Network ID to USIBMRA . Set the Control point name to BX2210T .
488
Configuring the APPN Branch Extender Select Branch Extender from the APPN folder.
Figure 461. 2210 Branch Extender APPN Configuration
We Selected:

Enable APPN Branch Extender. Permit search for unregistered LUs.
489
We selected:

Define Port for token-ring interface 0. Define Port for Serial-PPP interface 1. Configure against Token-Ring interface 0 and de-selected HPR .
490
From General-1 we:

Set the Link station name to RALYAS4A . De-selected HPR supported .
491
A MAC address of adjacent node of 400000000150 (see Token-Ring Line Description on page 465). Adjacent node type of APPN network node . Pressed Add .
492
Serial interface 1 APPN Port Configuration: We used the serial interface 1 to connect to the 2216. Select Configure against serial interface 1.
Figure 465. 2210 APPN Port Configuration for Interface 1
493
Serial interface 1 APPN Configuration: We used the serial interface 1 to connect to the 2216. Select Link Stations against serial interface 1.
From General-1 we:

Set the Link station name to BX2216 . De-selected HPR supported .
494
Select General-2 to enter the adjacent node type.

Adjacent node type APPN network node . Pressed Add . Note
Because Branch Extender has been enabled on the router, when network node is selected for adjacent node, Enable branch uplink is automatically enabled against Branch Extender .
495
Select Branch Extender to configure Branch Extender.
Figure 468. Branch Extender Configuration

Enable branch uplink has been automatically selected. Pressed Add .
496

We selected:

Save configuration as... Chose a Configuration name of 2210T in the config.cdb database. OK . Selected Configure once more . Create router configuration... A configuration file name of 2210T.CFG .
497
14.5 2210B Configuration


We selected a 2210 Model 24E with an empty slot.
498


An Ethernet ring interface A PPP interface to the 2216 An SDLC interface to the IBM 5494
Configuring the Ethernet Interface 1. From the Devices folder select Interfaces . 2. Select Configure against the Ethernet interface.
Figure 471. Configuring the 2210 Ethernet Interface
We set the MAC address to 1A002210000B.
499

500

501

We selected:

Enable APPN network node . Set the Network ID to USIBMRA . Set the Control point name to BX2210E.
502
We selected:

Define Port for interface 1 . Define Port for interface 2 . Used the Scroll bar to move to Serial interface 3 and selected Define Port for interface 3 . Link Stations against interface 3 and entered a Link station name of RAL5494A . Port configurations
As we are using HPR in this scenario, we were able to accept all the defaults from Configure port selection.
503

504
Interface 1 APPN Port Configuration: We used the serial interface 1 to connect to the 2216. Select Configure against interface 1.
Figure 477. 2210 APPN Port Configuration for Interface 1
505
Serial interface 1 APPN Configuration: We used the serial interface 1 to connect to the 2216. Select Link Stations against serial interface 1.
From General-1 we:

Set the Link station name to BX2216 . De-selected HPR supported .
506
Select General-2 to enter the adjacent node type.

507

We selected:

Save configuration as... A Configuration name of 2210E in the config.cdb database. OK . Selected Configure once more. Create router configuration... A configuration file name of 2210E.CFG.
508

Before we can start the APPN protocol on the AS/400, we have to vary on (activate) the network servers and the token-ring line descriptions on RALYAS4C and RALYAS4A. To vary on the network server on RALYAS4C, we used the following command:




VRYCFG CFGOBJ(BX2216) CFGTYPE(*CTL) STATUS(*ON)

To start the APPN session between RALYAS4A and the 2210, we used the following command to vary on (activate) the APPC controller description:
VRYCFG CFGOBJ(BX2210T) CFGTYPE(*CTL) STATUS(*ON)

The APPN device descriptions for the 2216 and 2210 CP-CP sessions will be autocreated by the AS/400s when the APPN sessions become active. We can see the status of the RALYAS4C network server and associated configuration objects using the command:
509
RALYAS4C 16:00:48
Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description FSIOP TOKENRING BX2216 BX2216 RAL5494A QRMTWSC QRMTWSC Status ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE ACTIVE/SOURCE ACTIVE/TARGET -------------Job--------------
RAL5494A00 RAL5494A00
QUSER QUSER
071029 071029
F23=More options
F24=More keys

Type options, press Enter. 1=Vary on 2=Vary off 5=Work with job 8=Work with description 9=Display mode status 13=Work with APPN status... Opt Description IPCSBASE TOKENRING BX2210T BX2210T Status ACTIVE ACTIVE ACTIVE ACTIVE -------------Job--------------
F23=More options
F24=More keys
510

F23=More options
F24=More keys
Figure 483. RALYAS4C Work with Configuration Status. Remote Workstation Controller Configuration.
We can now start an HPR session between RALYAS4C and RALYAS4A, for example, by starting a pass-through session by entering the command STRPASTHR RALYAS4A at RALYAS4C. Having established the pass-through session, we can see the status of the RALYAS4C AS/400 APPN information using the command WRKAPPNSTS.
511
Work with APPN Locations System: Type options, press Enter. 5=Work with sessions 8=Work with RTP connections 12=Work with configuration status -------Remote------Location Network Name ID BX2216 RALYAS4A RAL5494A USIBMRA USIBMRA USIBMRA -------Local-------Location Network Name ID RALYAS4C RALYAS4C RALYAS4C USIBMRA USIBMRA USIBMRA RALYAS4C
Opt
Controller BX2216
Number of Sessions 2 1 2 1 2 3
F9=Retrieve
F12=Cancel
1 2
CP sessions with the 2216 (BX2216) APPN sessions with RALYAS4A via the controller (PU) BX2216
3 APPN session with the the 5494 (RAL5494A) via the controller (PU) BX2216
512
Work with APPN Locations System: Type options, press Enter. 5=Work with sessions 8=Work with RTP connections 12=Work with configuration status -------Remote------Location Network Name ID BX2210T RALYAS4C USIBMRA USIBMRA -------Local-------Location Network Name ID RALYAS4A RALYAS4A USIBMRA USIBMRA RALYAS4A
Opt
Controller BX2210T
Number of Sessions 2 1 1 2
F9=Retrieve
F12=Cancel
1 2
CP sessions with the 2210 (BX2210T) APPN sessions with RALYAS4C via the controller (PU) BX2210T
The following screens were captured at router 2210A with the pass-through session between RALYAS4A and RALYAS4C still active. In Figure 487, the list cp-cp sessions command displays the status of 2210A s CP-CP sessions.
*t 5 CGW Operator Console +p appn APPN GWCON APPN >list cp-cp sessions CP Name Type Status Connwinner ID Conloser ID ======================================================================== USIBMRA.BX2216 NN Active B92A7CDB B92A7CDD USIBMRA.RALYAS4A EN Active B92A7CED B92A7CE9 APPN >
Note that in Figure 487 the 2210 sees the 2216 as an APPN network node.
513
In Figure 488, the list cp-cp sessions command displays the status of the 2216 s CP-CP sessions.
*t 5 CGW Operator Console +p appn APPN GWCON APPN >list cp-cp sessions CP Name Type Status Connwinner ID Conloser ID ======================================================================== USIBMRA.BX2210T EN Active 357FD0F0 357FD0EC USIBMRA.BX2210E NN Active 357FCD60 357FCD5F USIBMRA.RALYAS4C NN Active 357FCCC6 357FCCC5 APPN >
Note that in Figure 488 the 2216 sees 2210A (BX2210T) as an APPN end node.
514
Part 3. Additional Considerations

Part 4 contains additional considerations, particularly for router-based multiprotocol networks. The section includes a chapter on providing backup in router-based networks and a chapter on performance considerations for router-based networks.
515
516
Chapter 15. Providing Backup in Router Networks

This chapter deals with the provision of backup in router-based networks. This backup can be provided at different levels including physical link, node backup and dynamic protocol backup. To assist us in examining each of the techniques, we looked at a sample network consisting of three sites: one central site (site A) and two remote sites (sites B and C).
Figure 489. Basic Router Network: The M i n i m u m Configuration for a Network
Figure 489 shows the simplest network that could be used to link together the three sites. While this network will satisfy the basic protocol requirements, it suffers from the following potential problem areas: 1. Failure of the telecommunications link(s) 2. Failure of router ports 3. Failure of routers In the following sections in this chapter, we will look at ways to provide backup for each of these using a variety of different techniques and facilities.
517
15.1 ISDN Circuit Backup

Telecommunications failures are probably the most common point of failure within networks and are the cause of the most network down time. ISDN backup provides a simple form of link level backup available at the least cost. The most straightforward way of achieving this is to simply provide automatic backup for the circuit by placing an ISDN call around a failed circuit, and switching the router devices to use it. Once the circuit has been repaired, the mechanism should switch back to using the leased line and drop the ISDN call.
Figure 490. ISDN Link Backup: The Simplest Form of Link Backup
The IBM 2210 and IBM 2216 support such a scenario automatically with their WAN Restoral function (WRS) and ISDN adapters, which are available as a feature on IBM 2210 Models 14X and 24X, or as an integrated adapter on certain other models (127, 128, 1SX and 1UX). The IBM 2216 only supports Primary rate ISDN via an adapter (LIC-283 or LIC-292). The IBM 2210 X4X models can have either Basic or Primary rate ISDN. The ISDN backup is available for the following protocols:

PPP Frame relay
Please see 16.2.3, WAN Restoral Feature (WRS) - Dial Backup on page 528 and 16.2.4, Dial on Demand on page 529 for a discussion of the IBM 2210 dial support. When using 2210 s which are unable to have an ISDN adapter other
518
techniques must be used which involve the use of external ISDN backup units. These units are placed between the router and the circuit and continuously monitor the line to check for failures. In the event of circuit failure, they will automatically place the call and switch over the devices to use ISDN once the call is connected. Once the circuit has been re-established, they switch back and the call is dropped. The major advantages of this kind of backup are simplicity and cost. No special considerations need to be given to any of the protocols being run because all we are providing is physical backup of the telecommunications circuit. Going back to the list of events that we wished to protect ourselves from, we have satisfied number 1. We have not yet solved numbers 2 and 3.
15.2 Second Telecommunications Circuit
Figure 491. Second Communications Link: Updated Diagram Showing Second Circuit
With this technique, we provide a second circuit between the remote routers as well as the primary circuit into the central site. In the event of the primary circuit failing, we should like to provide automated recovery for each of the protocols. We may also want to use the secondary circuit for traffic between the two remote sites rather than traversing the links to the center. Let us examine each of the protocols in turn to see which ones will support such a configuration.
519
15.2.1 IPX
We take IPX first as it is the simplest. The routing mechanisms internal to IPX (such as, the RIP and SAP updates) will automatically route around the failure of one of the links. The route update will normally be triggered by the level two protocol (PPP or frame relay normally) reporting the failure of the link to the IPX protocol. We should also note that IPX routing (the RIP process) will calculate the optimum route between destinations based upon the number of hops within the network. Therefore in this example (see Figure 491 on page 519) we will route directly between the remote sites for traffic between the two as this is one hop less than the indirect route.
15.2.2 IP and DLSw

IP (and DLSw as it uses IP as transport over the wide area) will reroute around a link failure if a dynamic routing protocol is being used between the routers or LQM. The two most common dynamic routing protocols are RIP (Route Information Protocol) and OSPF (Open Shortest Path First). With static routes and PPP, LQM (Link Quality Monitor) provides a method to re-route dynamically without having to use RIP or OSPF.
15.2.3 HPR
HPR will also reroute around a link failure using its non-disruptive path switching capability.
15.2.4 Summary
Overall, what does this solution provide that the simple link level backup does not? In this case, we protect ourselves from link failure (item 1), port failure (item 2) but not router failure (item 3). Additionally, we also get the benefit of being able to use the second circuit for traffic between the two remote locations rather than having to go to the central site first. The ability to do this is dependant on running routing protocols that allow this kind of configuration. IPX and HPR will do this by default, but for IP we would again have to use a dynamic routing protocol such as RIP or OSPF.
520
15.3 Twin Routers

Finally, we look at a more complex solution which introduces a second router at the central site.
Figure 492. Twin Routers: Two Routers at the Central Site
The advantage of this solution is that it provides protection from all three failure points listed at the start of this chapter. However, while we have protected ourselves from the failure of a remote router, we have not protected ourselves from the failure of a central site router. Again, let us look at each of the protocols in turn to find out what we need to do to get them to utilize the backup that we have provided.
15.3.1 IPX
Again, IPX will automatically route around any node, link or port failures within the network without manual intervention. In the event of the central site router, the router port or the telecommunications link failing, IPX will automatically change its routing to route through its secondary link.
521
15.3.2 IP
IP will only route around failures if a dynamic routing protocol is used like RIP or OSPF. Static routing alone will not provide the backup that we require. Please refer to a previous section for a comparison of RIP versus OSPF (see 3.1.3, Summary of OSPF versus RIP on page 34). We should note that IP routing will be responsible for the integrity of the DLSw sessions between the routers. Finally, we need to consider devices on the central LAN to understand what needs to be done in order to allow them to utilize a backup router at the central site. To provide full automated backup in the event of one of the routers failing, a dynamic routing protocol must be run on the central site LAN. The most common protocol to run in this situation would be RIP (as OSPF is not supported on most workstations). If static routes were used, then any routes which pointed to the failing router would have to be changed to point at the alternate. Because IP is a connectionless protocol, there should be no session loss in the event of router failure. Also, providing that the network reroutes within the TCP timeout period (default 120 seconds) then there will be no loss of TCP sessions (FTP, TELNET, etc.) either.
15.3.3 Data Link Switching

As explained above, TCP is responsible for maintaining the integrity of the DLSw sessions within the backbone. We also need to consider what will happen to devices on the central LAN should one of the central routers fail. In the event of a central router failure, any sessions that are running through the DLSw of that router will be lost. However, after this session has failed, another logon attempt will automatically be processed by the alternate router.
15.3.4 HPR
HPR will reroute around a link failure using its non-disruptive path switching capability.
15.4 Summary
We close this chapter with a summary of the techniques used to provide degrees of backup in router networks. We are looking to provide backup for the scenarios of circuit failure, router port failure and total router failure. Backup facilities are available for each of these starting with simple ISDN circuit backup, moving through secondary links and finally ending with alternate routers. Generally speaking, the more backup that is required, the greater the cost of achieving it. Finally, each of the protocols must be configured to support the backup you require. For some (IPX and HPR) this is automatic. For others (IP) this involves the use of special dynamic routing protocols.
522
Chapter 16. Performance in Router Networks

In this chapter we will first present some general performance considerations for multiprotocol networks. We then review some of the useful features available on the IBM 2210 and 2216 routers. We cannot offer solutions as the subject of performance is every bit as diverse as the world of multiprotocol networking itself. Our aim is to make you think of areas that may affect your choices.
16.1 General Network Performance

Here we look at why understanding performance on your network is important and what things can contribute to the overall performance and overhead. We also explain circuit pacing which is important to understand for performance in SNA networks.
16.1.1 Why Network Performance Is Important

The idea that networking overhead is no longer important since networks are becoming faster, links are becoming more reliable and bandwidth is becoming more cost effective, is not a good business practice. Unnecessary overhead wastes bandwidth, increases network congestion and impacts response times. Minimizing congestion and overhead allows you to do more with a given amount of bandwidth. Tightening overhead will also reduce the frequency at which you need to acquire more bandwidth as usage of the network grows. Making more bandwidth available for actual work, by reducing overhead, will not only ensure that more business can be done, but it will also influence the level of service to your client. Different reasons lead companies to choose different networks, such as cost, technical strengths, applications/systems, tradition, corporate strategy, etc. Whatever the reason, network performance needs to be considered in each network. With different native networks coming together in a multiprotocol network, performance understanding and assessment becomes more complicated and more important. It is one thing to have performance in mind when you are building a network from scratch and you have a free hand to select the best performing protocols, the most efficient techniques for transporting different protocols across the network, the fastest boxes, links with greatest throughput and so on. However, in the real world you don t design a network from the ground up. The network is built around preferred systems, preferred applications, availability of products, availability of physical links or public network types, cost and so on. Generally you are tuning performance on pre-designed, existing networks or perhaps redesigning your current network.
16.1.2 General Considerations

This section is a mixed list of general points to be considered. They do not imply any specific network, but they are worth keeping in mind as you review your network options. One of the main things is that you understand your principle needs: availability, reliability, cost, response time and so on. Areas to consider are LANs, WAN links, routers, and factors limiting network capacity such as limiting LAN and WAN capacity to less than the link bandwidth.
523
Consider the effect of the physical media, data link layer protocols, practical management and actual usage patterns.
The network s physical media characteristics impose a limit on the network capacity. The data link layer protocols impose a lower limit on network capacity than physical media characteristics. Practical management needs and actual usage patterns impose a lower limit on network capacity than data link layer protocols.
Without knowledge of media and DLC throughput limitations, users overestimate their networking equipment requirements and subsequently purchase networking equipment with excess capacity. Excess capacity should not be chosen in lieu of other considerations such as future enhancement, scalability, reliability, ease of configuration, networking management, long term investment, life-time ownership costs, after sales service, etc. Traffic prioritization is important. Can you prioritize traffic from a specific application over other traffic of the same protocol, or are you only able to prioritize by protocol? Encapsulation requires processing overhead. Encapsulation means data is transported through all the layers of two protocols. Compression provides higher data rates thus improving response times at lower costs. Check whether compression is available on the routers or on the end systems. The Keep-Alive traffic requires processing overhead. SNA and TCP/IP both support timeouts. SNA is more precise since it was designed around the assumption that network bandwidth is expensive and scarce for organizations with many branches. TCP/IP is more relaxed; it was originally designed for campus networks with the assumption that bandwidth was inexpensive. IP networks typically throw away data when congestion occurs, and then endpoints retransmit causing further congestion. Due to flow control (windowing), SNA link utilization can reach a maximum of around 90% whereas for TCP/IP this maximum is around 50%. Sockets over SNA has been shown to be faster than native TCP/IP with file sizes over 8 KB. Should ARP storms occur under IP, processing the ARP requests and responses requires overhead. Another performance consideration is protocol broadcast traffic and the overhead of router-to-router exchanges. As each protocol is added, so is new flow between the routers. Network management is another internal flow to be considered. RFC 1490 s overhead is minimal compared to that of DLSw (including other router manufacturer s versions of DLSw).
524
Consideration must also be given for the future. New applications are likely to require greater bandwidth. New graphics and multimedia applications are becoming available with ever increasing bandwidth needs.
16.1.3 Router Considerations

Performance is a hot subject in the multiprotocol router market today. However, it is difficult to make valid comparisons. Many vendors quote theoretical box throughput. Performance reports often come without specification of the test environment or the complete network in which the tests were made. A test environment generally has no resemblance to real environments. Traffic may have been one way only. Measurements are often done with 64-byte packets only, whereas much larger frames are common on typical router networks. Performance varies by protocol and packet size. How a router performs is much more than a statement of top speed. When router capacity is less than the actual link demand, the router is the bottleneck; the router needs reasonable headroom (unused capacity) for future expansion. However, the maximum useable capacity of the media connections should be considered, as there is no point having headroom you can never use. The maximum useable capacity of a media may be much less than its bandwidth. A customer perceives the network performance by the response time and/or throughput the end user sees for his applications. The router is one of the many contributors to the response time and its performance in the customer environment is really defined by its contribution to overall system response time and its effect on throughput. A minimum of 64 kbps lines are recommended for links between routers. The result of moving from 9.6 or 19.2 lines on a single protocol network to 64 KB lines in the multiprotocol environment is usually equivalent but never greater. A multiprotocol network is never faster than a native network.
16.1.4 SNA Circuit Pacing

SNA circuit pacing can be useful when applications that do not use fixed end-to-end SNA pacing transfer large files across a relatively slow speed WAN. As the routers involved are performing local acknowledgments for LLC2 packets on the faster LAN side, the application believes that all the packets that it has sent have been received and processed by the recipient and proceeds to send even more data. This can cause the bulk data being sent to build up on the router s transmit queues and block interactive traffic. There are two ways in which to overcome this problem which can be used in parallel. First, the SNA applications should perform end-to-end pacing. This will ensure that even if local LLC2 acknowledgments are received the application will not send more data until its SNA pacing window is opened by the remote application. In the AS/400, this support is enabled in OS/400 V3R2 and V4R2. The second way of eliminating this problem is by the use of SNA circuit pacing on IBM router products. On the IBM 2210 and 2216, circuit pacing is enabled by specifying the number of LLC2 frames that can be acknowledged by the router locally before an LLC2 RNR (Receive Not Ready) is sent back to the sending application asking it to suspend transmission. Once the outbound queues on the router have been cleared, an LLC2 RR (Receive Ready) is then sent to the application asking it to resume transmission. On the 2210 and 2216, the LLC
525
window size can be changed either by an online command or by the MRS Configuration Program (2210) or MAS Configuration Program (2216). The LLC window size (Transmit Window) specifies the number of I frames that can be sent by the 2210/2216 and over the TCP connection before an RR is received from the remote router. If this window expires, an RNR is sent back to the sending station until the RR is received from the remote router. The default window size is set to 2 for SAP X 00. If DLSw is being used, then an additional window size should also be configured for SAP X 04. To perform this operation please refer to the 2210/2216 product manuals.
16.2 IBM 2210/2216 Features

We will look at some useful functions on the IBM 2210 and 2216 routers which can assist with performance. We will then see how we improved interactive response time over batch traffic on the AS/400s in a 2210 scenario. This is a shortened version of the information that can be found in Chapter 9 of IBM 2210 Nways Multiprotocol Router Description and Configuration Scenarios , SG24-4446. For more detailed information refer to the product manuals.
16.2.1 IBM 2210/2216 Bandwidth Reservation (BRS)

The idea of BRS is to reserve specific amounts of the WAN bandwidth for certain types of traffic. This will allow you to prioritize traffic and ensure WAN availability to your most important traffic when your network is congested. BRS is supported over PPP serial links, frame relay and dial connections and applies to the outbound traffic. You assign a name to a percentage of the bandwidth called the class name. There are two default classes, which you cannot delete or change the names of. You can change the percentage bandwidth for these. They are: LOCAL with a default of 10% bandwidth DEFAULT with a default of 40% bandwidth
Figure 493. Example of Bandwidth Assigned Classes
526
Note:
Class names are case sensitive.
The reserved percentage of bandwidth is the guaranteed minimum. If the network is running at full capacity and the bandwidth is full for a specific class, messages for this class get held up and queued. If the network is running at a low capacity but one class is busy, that class can exceed its assigned bandwidth and use some of the unused bandwidth assigned to other classes. Within a class you can assign priority to specific types of traffic. Class and priority can be assigned to protocols, filters and tags:
Protocols - IP, ARP (with ASCII console only, not available on MRNS), IPX, ASRT (bridged traffic) and APL, AP2 (AppleTalk phase 1 and 2). Filters such as RLOGIN-IP, TELNET-IP, NetBIOS, SNA bridged, SNMP-IP, DLSW-IP (SNA in DLSw), SDLC-IP and others. Tags - Five tags - tag1... tag5 - these come from MAC filtering on bridged traffic.
You assign BRS throughu the BRS feature in the TALK 6 Config function, using commands like - feature brs, add-class, assign, enable, interface, list, etc. We will look at an example configuration of BRS in 16.3, IBM 2210 Performance Scenario - User Response Time versus Batch on page 532.
16.2.2 MAC Filtering (MCF)

Filters based on source and destination MAC addresses are applied during bridging. The advantage of MCF is to stop unwanted traffic from crossing the WAN part of your network. It will allow you to cut out frames such as broadcasts, and in this way it helps with the load on the WAN where bandwidth is expensive in terms of cost and availability. It can also be used for low level security to stop traffic from particular LAN segments from accessing your LAN segment. MCF is supported over token-ring, Ethernet, and PPP serial links only. MAC filtering over a dial on demand serial interface is not supported because dial on demand is not supported over bridging, MAC filtering is supported only over bridging. You can have INPUT and OUTPUT filters on interface 0 (LAN) and interfaces 1 and 2 (serial). A filter can:

Include bridge packets as normal. Exclude packets. Tag packets with a number 1 to 64, so BRS (bandwidth reservation) can be based on these tag numbers.
Tagged packets are always forwarded via the bridge. BRS applies to tagged packets that will go over the PPP link.
527
FILTERS FILTER Default Action FILTER LISTS LIST List Action FILTER ITEMS ITEM Used to Compare
Figure 494. MAC Filtering
To implement MCF you define a filter with a default action. You create lists of items based on MAC addresses which are used for comparing against the incoming or outgoing MAC frame. You assign an action to the list, and you assign one or more lists to a filter. You can have more than one filter in place. The 2210 and 2216 match a frame to the first matching filter item found (the order of lists/entries is therefore important). They perform the filter action for that list. If no match is found, they perform the default action for the filter. You do not have to specify every single MAC address you want as an item; you can specify a range. The filter list item is defined with a corresponding hex mask, saying which bits to compare for a match. This is similar to IP subnet masking. You configure MCF via talk 6, the configuration utility and commands such as:
Feature MCF Create Attach Enable Add Set-action etc...
16.2.3 WAN Restoral Feature (WRS) - Dial Backup

WRS on the 2210/2216 allows you to back up your primary leased PPP serial link via a switched V.25 bis PPP serial link, or via ISDN. It means that you will be able to provide constant performance and availability to your users, in the event of a failure on your primary link. When the primary link fails, all protocols automatically switch over and survive the switchover. When the primary PPP link comes back, the 2210/2216 automatically drops the switched link and swaps the protocols back transparently to the user.
528
***************** Switched * * 2210 -----------2210 *4 Mbps Token-Ring* * LAN * ***************** 2210TR 2210ETH 64K Leased Ethernet B LAN Host
Figure 495. Dial Backup (WRS) via V.25bis Switched Serial Link
The performance of WRS via V.25 bis switched serial link as shown in Figure 495 has been tested. It was found that while the routers were switching over to the backup switched link, the VTAM user, (B in Figure 495) was in pending clock for 40 seconds. When the primary link came back up, WRS switched back without any waiting on the part of the SNA session. Refer to Chapter 15, Providing Backup in Router Networks on page 517 for more detailed information on backup in router networks.
16.2.4 Dial on Demand

As the name implies, dial on demand allows an IBM 2210/2216 to dial into the backbone router network as and when it needs to communicate. This is ideal for a remote site which only needs wide area connectivity intermittently. You can take advantage of the cost saving of using a switched network for low usage instead of a leased line. When the 2210/2216 detects that a packet needs to be sent over the switched link, it automatically dials the customized phone number. You can customize different phone numbers corresponding to different remote locations, but only one can be used at a time with the exception of ISDN (BRI and PRI). REMOTE SITE BACKBONE ROUTER NETWORK
********* 2210 2210 * 4MB TR * V.25bis V.25bis * LAN * Modem Modem * * 2210TRSwitched ********* Network 2210ETH Ethernet LAN 2210
Figure 496. Dial o n Demand
Dial on demand is only supported over a switched V.25 bis serial links and ISDN links. Dial on demand supports TCP/IP (DLSw and tunnel) and IPX protocols only. It does not support bridging except for tunnel bridging.
529
Performance Considerations Some performance considerations when configuring dial on demand are as follows:
The switched line is automatically dropped when no data is sent for the length of time equal to the configured idle timer. You should configure a realistic value but not leave the link up unnecessarily. Use static routes for IP routing over dial on demand. This prevents establishing connections for every routing update. For DLSw over dial on demand, do not enable the Keepalive parameter. Keepalive messages could keep the connection up permanently. For IPX routing specify large RIP and SAP update intervals, to ensure dial on demand circuits are not established too frequently for RIP and SAP messages. Dial on demand cannot be used to provide additional bandwidth over a switched link where the primary link is overutilized. ISDN channels can be bundled together to increase throughput.
Dial on demand is configured via the ASCII console on the 2210/2216. You must configure two interfaces, the V.25 bis Physical interface and the Logical Dial-Circuit interface. To do this, you first define the interfaces, then customize the V.25 bis interface, and then customize the dial circuit interface, as shown in the following example.
530
Define The Interfaces: *Talk 6 Config> set data-link V25bis 2 (using serial interface 2) Config> add device dial circuit (to define one or more dial circuits) Config> list devices (to find the dial circuit interface number) Config> add v25-bis-address local-site 12345678 (define a phone number and give it the name local-site) Config> add v25-bis-address remote-site 87654321 (define a phone number and give it the name remote-site) Config> list v25-bis-address (to verify the list of numbers added) Customize the V.25 bis Interface: Config> network 2 V.25bis Data Link Configuration V.25bis Config> set local local-site V.25bis Config> set timeout-no-answer 60 V.25bis Config> set retries-no-answer 5 V.25bis Config> list (to verify) V.25bis Config> exit
(the physical v.25 bis interface) (assigns this number locally)
Customize the Dial Circuit Interface: Config> network 3 (or whatever interface number was assigned to the dial circuit) Circuit Configuration Circuit Config> set net 2 (map the logical dial circuit to the physical V.25 bis interface) Circuit Config> set calls outbound (or inbound or both - to specify in what direction the switched connections can be made) Circuit Config> set idle 30 (the idle-timer) Circuit Config> set destination remote-site (sets remote phone number for the dial circuit) Circuit Config> encapsulator (to set the PPP parameters for the switched link) PPP Config> list all Change any PPP parameters required with the set command PPP Config> exit Circuit Config> list (to verify) Circuit Config> exit
Figure 497. IBM 2210 V.25 bis Configuration
Refer to IBM 2210 Nways Multiprotocol Router Description and Configuration Scenarios , SG24-4446 for more information on dial on demand.
16.2.5 NetBIOS Facilities

NetBIOS, like some other protocols, was designed for a LAN and sends out a lot of broadcast-type traffic which can have an impact on performance when it goes across a WAN. There are three NetBIOS facilities available on the IBM 2210/2216 to help:

NetBIOS name caching NetBIOS filtering DLSw
We will summarize briefly what these facilities offer. For more detail and information on configuring, refer to IBM 2210 Nways Multiprotocol Router Description and Configuration Scenarios , SG24-4446 and the related product manuals.
531
NetBIOS Name Caching: For a 2210/2216 configured as a bridge, you can implement the following two types of NetBIOS name caching:
Name Caching for Name-Query Frames - The name caching process allows the IBM 2210/2216 to convert All Route Broadcast name-query frames into specifically routed name-query frames. Duplicate Frames Filtering for add-name, add-group-name and name-query frames to reduce the amount of these frames over the WAN.
If both of the above are enabled then duplicate frame filtering is performed first. NetBIOS Filtering Facility

Filters are applied during bridging. They are based either on the NetBIOS host name or on certain bytes contained in the NetBIOS header frame. They can be specified for traffic in either direction, input or output on one or more interfaces. A filter can include or exclude frames. Host Name Filter - This means you filter based on the source or destination name fields in name query packets. Byte Filter - This means you filter using a byte string which will be compared against all NetBIOS packets.
As with MCF described earlier, a filter is made up of filter lists (which are made up of filter items). Here, however, actions are assigned to a filter item and a default action is assigned to the filter list. DLSw: DLSw also provides mechanisms that can be used to filter the amount of NetBIOS broadcast traffic flowing over the WAN.
16.3 IBM 2210 Performance Scenario - User Response Time versus Batch
For all the reasons we have discussed earlier in this chapter, measuring performance realistically in a lab environment is difficult. However, we did some testing and will present some results which may be useful to give you a general feel for what user response times you might expect. We used a simple 2210-to-2210 network. There was no traffic on the network apart from our test traffic. The aim of our test was to see how interactive response between the two AS/400s (RALYAS4B and RALYAS4A) performed when there was concurrent batch traffic between the two. We wanted to tune the performance so that the interactive passthrough user was not aware of the batch transfers across the WAN.
532
The network used in the tests is as shown in Figure 498.
Figure 498. IBM 2210 Router Network, Overview
Tests The test user was signed on at RALYAS4A and was in a passthrough session to RALYAS4B. The normal response time in the passthrough session was 2 seconds. The user pressed F4 and F3 in succession continuously and measured the response times in receiving these panels. We then put batch traffic over the WAN by transferring files between the two AS/400s and measured the response time for the passthrough user. We used the same physical file in all the tests. Our tests and findings are as follows:
533
1) FTP session from B to A, GET of a file of approx 4 MB, Name Format 0, ASCII transfer Results - 4042012 bytes in 707.599 seconds, transfer rate 5.712KB/sec Passthrough user R.T. (response time) = 5 seconds 2) ASCII, pre-created file on target to receive data Results - 4042012 bytes in 626.374 seconds, transfer rate 6.453 KB/sec Passthrough user R.T. = 5 3) Changed Maxframe size for SAP AA to 265 from 1496, Name Format 0, file not pre-created, ASCII first, then binary and EBCDIC. Results - 4042012 bytes in 793.865 seconds, transfer rate 5.092 KB/sec Passthrough user R.T. = 5 Binary - 4327488 bytes in 756.395 seconds, transfer rate 5.721 KB/sec EBCDIC - 4009228 bytes in 766.497 seconds, transfer rate 5.231 KB/sec 4) Same as above but sent two FTPs of the same file concurrently Results - Passthrough R.T. varied from 5 to 8 seconds 1) 4042012 bytes in 1210.505 seconds, transfer rate 3.339KB/sec 2) 4042012 bytes in 1211.909 seconds, transfer rate 3.335KB/sec 5) SNDNETF of the same file from RALYAS4B to RALYAS4A, SNADS was using Mode Blank with a pacing value of 3, maxframe for SAP 04 = 1496 Results - Passthrough user R.T. varied from 4 to 7, but more often 7 seconds SNADS transfer rate, based on dstlog, the time between *SND and *ARV entries = 6 mins 3 secs 6) Above test but changed SNADS to use mode #Batch with pacing = 1 Results - Passthrough user R.T. = 2 (same as with no batch traffic) SNADS transfer rate, based on dstlog, the time between *SND and *ARV entries = 19 mins 40 secs 7) Same as test 1, but set Bandwidth Reservation on the 2210 to give DLSw traffic 60% of bandwidth. Result - Passthrough user R.T. = 2 seconds (same as with no batch traffic)
534
16.3.1 Setting Bandwidth Reservation

The 2210/2216 bandwidth reservation is set via talk 6 as shown in the following example. *Talk 6 Config> feature brs Bandwidth Reservation User Configuration BRS Config> interface 1 (WAN interface) BRS [i 1] Config> enable brs Please restart router for this command to take effect. BRS [i 1] Config> exit Config> exit Ctrl P *RESTART Are you sure you want to restart the gateway? (Yes or [No]): yes *Talk 6 Config> feature brs Bandwidth Reservation User Configuration BRS Config> interface 1 BRS [i 1] Config> change-class Class name [DEFAULT]? DEFAULT Percent of bandwidth to reserve [40]? 30 BRS [i 1] Config> add-class Class name [DEFAULT]? dlsclass Percent of bandwidth to reserve [10]? 60 BRS [i 1] Config> assign Protocol or filter name [IP]? dls Class name [DEFAULT]? dlsclass Priority (URGENT/HIGH/NORMAL/LOW) [NORMAL]? high BRS [i 1] Config> list (to verify) BRS [i 1] Config> exit BRS Config> exit Config> exit Ctrl P *RESTART Are you sure you want to restart the gateway? (Yes or [No]): yes
Figure 499. IBM 2210 BRS Configuration Example
Note:
Class names are case sensitive.
16.3.2 Summary
With SNADS traffic using mode #Batch with pacing set to 1, and BRS implemented on the routers allocating 60% of bandwidth to DLS traffic, the passthrough user experiences no change in response time, when SNA or TCP/IP batch file transfers are running concurrently.
16.4 General Points for the IBM 2210 and 2216

With data link switching, the router is sending link level pacing acknowledgments to the AS/400 inviting it to send more frames if session level pacing permits. The AS/400 uses the session pacing window set in the Mode description at the start of a conversation, but it uses adaptive pacing so the window may change. This could cause the AS/400 to send frames too frequently which leads to congestion on the router queues or across the network. With OS/400 V3R2 and V4R2, the AS/400 will use fixed pacing exclusively, when the Class of Service Description (COSD) specifies low transmission priority.
535
Data link switching frames are processed by the main processor on the routers and not handled on the card. Processor utilization becomes the primary throughput limiting resource as traffic loads increase. The data flow and TCP buffering increase the latency through the router. TCP consumes relatively large amounts of router memory and processing power since it requires end-to-end acknowledgments and sequence number tracking. DLSw requires two TCP connections between every router pair.
536
Chapter 17. Network Management in Router Networks

This chapter will address some of the areas of network management. The management of router networks is a large and complex issue; We will focus in on the following points:

Router configuration and maintenance Router operation and problem determination Network monitoring
17.1 Router Configuration and Maintenance

In this section we will address the areas of router configuration and router maintenance. In Router Configuration we will look at ways of updating router definitions to ensure that we do not cause disruption. Router Maintenance will cover software maintenance issues.
17.1.1 Router Configuration

Over time, router configurations generally do change. This change may be the result of some extra IP routing that is required or maybe some SNA traffic is now required between two sites that previously did not need it. Whatever the details of the changes that are required to the router definitions, it is vitally important that the updates are made causing the least possible disruption. Dynamic change is the key to this point. definitions without causing any impact to however, a change causes a restart of a restart of the router, then we have to be activities. If we can make changes to the router users, then our task is easy. If, particular protocol, or even worse a very careful how we manage such
17.1.1.1 IBM 2210 and 2216

Some of the 2210 and 2216 parameters are dynamic, but most are not. However, the position with the 2210/2216 becomes more complicated due to the fact that there are two methods of configuration, either online or by the 2210 MRS/2216 MAS Configuration Program. We take the 2210/2216 Configuration Programs first. When making updates to any parameters using this utility, the router must be rebooted to bring any changes into effect. This means that the router will have to be rebooted manually at some prearranged time. The 2210/2216 Configuration Program currently does not allow you to activate configurations at a set time and day. When configuring 2210/2216 parameters online, any parameters that are changed using the talk 5 option are regarded as dynamic. Most parameters that are changed using the talk 6 option are not dynamic and require a router restart. Please note that any parameters that are changed using talk 5 are not permanent and will be lost when the router is rebooted next. You must remember to make the changes permanent either by use of talk 6 commands or via the MRS/MAS Configuration Program. Virtually all DLSw parameters within the 2210/2216 are dynamic, even those changed by talk 6 commands.
537
17.1.2 Software Maintenance

Software maintenance covers the area of applying new software levels, PTFs etc. Like router configuration, this area is very complex and full details should be gained from the IBM 2210 and IBM 2216 product manuals. This section will briefly outline the procedures required to maintain software on the 2216 and 2210.
17.1.2.1 IBM 2210 and 2216

Software can only be distributed to the 2210/2216 over the network. Two options are possible here. First, the 2210/2216 can be configured to retrieve its load module from a BOOTP server somewhere in the network. This means that to perform maintenance you simply need to update the module on the BOOTP server. However, this means that the 2210/2216 will load the code over the network each time it is rebooted, which can again cause network congestion. The second method is to use the tftp program to transfer the new load module to the 2210/2216 when an upgrade is required. The 2210 can store multiple load modules in its flash memory (dependant on the size of its flash memory), and you can select which image to load at reboot time. The 2216 can hold 2 copies of its operating system and then, like the 2210, you can select which copy to load at reboot time . Both the 2210 and 2216 require a reboot to activate any new code updates.
17.2 Router Operation and Problem Determination

This section of the document covers the areas of router operation and problem determination. Again, like the preceding section, this is a very complex and difficult area and you should refer to the IBM 2210 and IBM 2216 product manuals.
17.2.1 Logging on to a Router

The following are the three general ways of logging on to a router: 1. Local console 2. Remote modem connection 3. TCP/IP TELNET The first two options above are very similar. A local ASCII console or ASCII terminal emulator can be attached to the serial port of the router using standard emulator settings. The IBM 2210 and IBM 2216 will both work with the following settings:

8 data bits 1 stop bit No parity Speed 9600 bps
A remote modem connection may be useful to monitor a remote router. Both the IBM 2210 and IBM 2216 support the attachment of a V.24 modem to the serial port and connection to a remote terminal emulator using the same settings as those shown above. In a normal mode of operation, however, the easiest way to log on to the router is by TCP/IP TELNET. The IBM 2210 uses VT100 and the IBM 2216 uses VT220 (VT100 will work but in a limited way).
538
17.2.2 Operating the IBM 2210 and 2216

The IBM 2210 and 2216 provide operational and problem determination support for a logged-in user. All of the operational options with the exception of reboot are held under talk 5. The following table lists some of the more common activities that you may want to perform:
Table 22. 2210/2216 Operational Commands Action Reload router code and restart router Restart router Check network interface IP Ping Commands reload restart (2210 only)

talk 5 interface interface_number talk 5 protocol ip ping ip_address talk 5 protocol dlsw list tcp sessions talk 5 protocol protocol_name dump talk 5 protocol ipx slist
Check DLSw sessions
Check protocol routing table
Check IPX Server table
17.3 Network Monitoring

The final topic that we will cover in this chapter is that of network monitoring. Most routers today, including the IBM 2210 and 2216, provide extensive management and reporting data. Most routers can be configured to send this management data to a central reporting function known as a network manager. This network manager is generally a networked application responsible for receiving the management data and providing real-time reports and alerts from it. Generally the protocol used to send data to and from the network manager is SNMP (the Simple Network Management Protocol) which runs over an IP network. Each router maintains all of its management information in its Management Information Base (MIB). The MIB is a standard defined database format which is supported by most routers. This means that a network management application (such as Tivoli NetView), which understands the MIB format, is capable of managing most router products. The current MIB standard is known as MIB II and contains details about all of the router s functions.
Chapter 17. Network Management in Router Networks
539
17.4 Summary
This chapter has briefly looked at some of the aspects of network management. We have looked at router configuration and software maintenance procedures for the IBM 2210 and IBM 2216 highlighting some ways in which activities can be done non-disruptively. We have moved on to cover some of the simple techniques that can be used from the router devices to perform simple operational activities and problem determination.
540
Chapter 18. AS/400 and Printing in a Multiprotocol Network

In this chapter we look at the large and complex issue of printing support in multiprotocol networks. We discuss some of the potential printing problems faced when migrating from a pure SNA network to a multiprotocol environment. The key point to focus on during any migration exercise is to ensure that we provide the same level of print support, in terms of function and performance, that is present in any existing solution. This is not a straightforward proposition. Print support within multiprotocol networks has to cater to a wide variety of print applications, network connectivity options and printing hardware. In particular, we have to look at support for different printer data streams (for example, IPDS), different applications, and different network connectivity options such as twinax, token-ring and Ethernet. This chapter does not address all of the issues within printing support over multiprotocol networks. It is intended to help networking specialists understand the concepts of printing in a multiprotocol environment and examine some of the available options. Printer specialists will understand the applications, the printer data streams and the capabilities of the printers. However, when printing is done across the network, the following responsibilities fall on the networking specialist:
To ensure performance is maintained and to improve response times for printer output over the network To understand the interoperability of different printers attached to different systems around the network How print output is transported using different protocols To what extent the AS/400 can be used as a central print server or how AS/400 print output can be transferred to other print servers
This chapter provides you, from a networking and AS/400 perspective, with information to help you answer these questions.
541
18.1 Overview
Many different applications produce output that needs to be printed. This could be the result of a remote database query or the result of a user requiring hardcopy output of some mail. Whatever the source of the data to be printed, the path that the data flows is always the same. An application is responsible for actually controlling the overall print operation and the print device. This application will create a print data stream which consists of the following two components:
The set of instructions used to control printer functions (for example, highlighting and fonts) The actual data to be printed
The print data stream will be handed down to a communications protocol (for example, SNA or TCP/IP) which is responsible for delivering it to the destination print device. The communications protocol then has to use network connectivity, token-ring for example, to physically transmit the data to the required destination. Each of these three independent layers needs to be interoperable between the printer driver and the printing device as illustrated by Figure 500. Application IPDS Network SNA Link Ethernet AS/400 Printer attached to IBM 5494
Figure 500. Interoperability in Printing
The above example is of a printer (printing device) which is twinax attached to an IBM 5494. The 5494 connects to an AS/400 (printer driver) by an Ethernet LAN connection. We need to achieve interoperability here on the following three levels:
First, the 5494 and AS/400 must be able to share the same physical communications medium (here it is LAN attachment). Second, the 5494 and AS/400 must be able to share the same network protocol (here it is SNA). Finally, and most important, the printer must be able to understand the printer data stream that the AS/400 application generated and sent to it.
In the following sections, we look at solutions which can satisfy the three interoperability requirements.
542
18.2 Migrating the Current Environment

AS/400 52505394 Screens Printer
Figure 501. Classic AS/400 Networking Environment
Main Office
Remote Site
When migrating from a classic AS/400 network scenario to a multiprotocol environment, we must always ensure that we consider the question of how to accomplish equivalent printing support. The following questions must be addressed at the design stage of the new network:
Can the current printers still be used? Twinax printers, especially twinax IPDS printers, offer a sophisticated level of printing functions. This level cannot always be achieved by ASCII printers. Can the current printers be used by other systems in the new network? How can the printers or workstation controllers be integrated into the new network? The 5394 does not offer simple migration into a router network as it cannot be LAN-attached. Is the network protocol (for example SNA) supported by the new network? What effect will sending large print files have on the network?
There are many potential ways in which we can design a network to answer the previous questions for the scenario shown in Figure 501. These methods could include the following scenarios:

Attaching the IBM 5394 via SDLC to the router Replacing the IBM 5394 with a LAN-attached IBM 5494 Replacing the twinax printer with a LAN-attached printer
The best solution will depend on the individual s requirements. The following diagram illustrates one potential solution.
543
AS/400 | * * * ** * * * * Token-Ring * * * * ** * * * Router Router 52505494 Screens Printer UNIX

Figure 502. Migrated Printing Environment
Main Office
Remote Site
If we consider the replacement of actual printers, interoperability has to be checked between the printer and the application. The following questions must be addressed:

What printer data stream do we use currently? Will the new printer also support this data stream? Will the new printer support this data stream over the multiprotocol network that we install?
We may also be opening up the printing environment to other users. For example, if we LAN attach a new printer, we may require that other LAN users be able to use this facility. Again, we need to ensure that the printer will support and work with any new print applications. One of the biggest factors is performance. The printing of large volumes of data can influence interactive traffic and performance in any environment. Multiprotocol network environments also suffer from the same problems as to how to minimize the impact of printing on interactive users. In the next sections we will attempt to answer the following questions. This information should help you to propose solutions to the previous questions.

What are the various printer data streams that AS/400 applications generate? Which printer data streams is the AS/400 able to receive as print server?
544
Which printer data streams are understood by which printers and how can printers be connected to the AS/400?
18.3 AS/400 and Printer Data Streams

ApplicationSCS SCS SCS Printer SCS AFPDSASCII ASCII Printer SCS IPDS IPDS IPDS Printer AFPDS AS/400
Figure 503. AS/400 and Printer Data Streams
The AS/400 can generate the following printer data streams:

SNA Character Stream (SCS) Intelligent Printer Data Stream (IPDS) Advanced Function Printing Data Stream (AFPDS) Line data stream (LINE) AFPDS line (also called mixed mode) data stream (AFPDSLINE)
SCS mainly covers line printing. SCS printers are twinax attached printers. The AS/400 is able to transform SCS and AFPDS into ASCII data streams, such as PPDS, PCL4, PCL5, by using the Host Print Transform function which is part of the OS/400. Printers understanding ASCII printer data streams are referred to as ASCII printers, PC printers, personal or workstation printers. On the AS/400, the term USERASCII is used to represent all ASCII printer data streams such as PPDS, PCL4, PCL5. AFPDS allows the printing of complex documents and allows the integration of graphics, forms and text. Before it is transmitted to the printer, the AFPDS format is converted into the IPDS data stream by the Print Services Facility/400 (PSF/400), a feature of the OS/400 operating system. The IPDS generated by AS/400 applications is a subset of the full IPDS with the same functions but without the two-way dialog with the print driver. We also mention PostScript, which is a printer data stream similar to AFPDS used mainly by PC printers. Note that AS/400 does not generate PostScript printer data streams. For detailed information on AS/400 and data streams, see the redbook AS/400 Printing V , SG24-2160.
545
18.4 AS/400 as Print Server

The AS/400 is also capable of receiving print output from other systems and sending it to printers controlled by the AS/400. The AS/400 can receive print output from many different sources in the network including the following list:

From From From From
a Client Access/400 user a TCP/IP user via TCP/IP LPR another AS/400 via SNADS ODF a System/390 via VM/MVS Bridge
The received print output is queued on one specified queue. Each queue usually only services one specific printer. Print Requester AS/400 as Print Server
Printer
Figure 504. AS/400 as Print Server
The AS/400 is able to receive and handle the following data stream types: SCS, IPDS, AFPDS, LINE, AFPDSLINE and ASCII. AFPDSLINE is also named mixed mode. The AS/400 can perform some conversions on received printer data streams such as the following:

SCS to ASCII and AFPDS to ASCII with the host print transform function SCS, IPDS, AFPDS, LINE, and AFPDSLINE to IPDS with the Print Services/400 (PSF/400)
In addition, any ASCII printer data stream, even PostScript, can be spooled on AS/400 and forwarded to, or printed on, an ASCII printer without alteration. In all cases, the target printer must always be able to understand the data stream which is sent to it.
546
18.5 AS/400 Printer Support

Print output generated by AS/400 applications is put into a print output queue. Print output received from other systems and workstations is queued the same way. The following subsections will provide an overview on the various printers supported by the AS/400.

Printers attached to local and remote workstation controllers LAN-attached printers Printers attached to workstations such as PCs Printers managed by LAN print server Printers controlled by other systems
From a networking point of view, the following three aspects have to be observed:
Link type: twinax, LAN or WAN. What is the connection between the AS/400 and the printer? Network type: SNA, TCP/IP or other protocols. What is the network protocol between the AS/400 and the printer? Printer data stream: ASCII, SCS, IPDS or AFPDS. What is the data stream supported by the printer? Any transformation possible (such as using Host Print Transform or Print Services Facility/400)?
With this information the networking specialist can take printer requirements into account when designing a network. Some of the areas that are not covered in this section include:

Printer functions Printer sharing among different workstations and servers Printer capacity
These are printer-specific aspects which you need to discuss with printer specialists.
547
18.5.1 Printers Attached to a Local or Remote Workstation Controller

Local AS/400 printers are attached via twinax cabling. The AS/400 has no channel-attached system printers. Twinax printers are also attached to the IBM 5494 or IBM 5394 remote workstation controller. The IBM 5494 can be LAN or WAN attached. The IBM 5394 is WAN attached only. AS/400 LAN or Twinax ASCII WAN WSC WSC Adapter IBM 5394 Twinax Twinax Printer Printer IBM local or 5494 ASCII Twinax remote Printer Display Twinax Printer IBM 3174 Coax Printer ASCII ASCII ASCII Printer Display Printer
Figure 505. Printers Attached to a Local or Remote Workstation Controller
548
Type Connection to Printer Data Stream of Printer Support Printer Attached to Link Network ASCII SCS AFPDS /IPDS Twinax Twinax WSC Twinax SNA yes yes Twinax IBM 5X94 LAN/WAN SNA yes yes ASCII ASCII WSC Serial ASYNC yes yes 1 yes 2 Coax IBM 3174 Coax SNA yes
Note:
1 This is the conversion from SCS to ASCII performed by the OS/400 host print transform function. 2 The conversion from AFPDS to ASCII is performed by the OS/400 host
print transform function. The IPDS data stream cannot be transformed by the host print transform.
549
18.5.2 LAN-Attached Printers

There may be a requirement to attach printers directly to a LAN without a controlling server system. A large variety of printers in this area can receive print output from the AS/400.
AS/400 Twinax ASCII LAN WSC WSC Adapter IPDS, PSF/2 DPF, IPDS ASCII ASCII ASCII PSF Direct Printer Printer Printer Printer (LexLink) (PJL)
Figure 506. LAN-Attached Printers
Printer attached to PSF Direct. PSF Direct support is provided by PSF/2 (V2) and PSF/6000. PSF/2 Direct replaces the Remote Print Manager (RPM) V2 and offers more possibilities. PSF Direct allows the attachment of any IPDS page or matrix printer, and PPDS or PCL5 compatible ASCII printers. PSF Direct allows the use of printer resident fonts. With PSF Direct, the AS/400 operator controls the remote IPDS printers. For example, printer messages are returned to the AS/400.
Printer attached to PSF/2 Distributed Print Function (DPF). The main difference between PSF/2 DPF and PSF Direct is in the area of printer operator control. With PSF/2 DPF the PC administrator controls the printer, which means that no printer messages are returned to the AS/400. In addition, PSF/2 DPF does not support IPDS matrix printers and does not support resident fonts (only host resident fonts are supported).
LAN-attached IPDS printers. The following IPDS printers can be attached directly to the LAN: Any IPDS printer with an IBM AFCCU (Advanced Function Common Control Unit), such as an IBM 3130, IBM 3160, IBM InfoPrint 60/62, IBM InfoPrint 3000, and IBM InfoPrint 4000. Any IPDS printer with an internal LAN-attachment card, such as an IBM Network Printer (4312, 4317 or 4324) or an IBM InfoPrint 20.
550
Any IPDS printer attached to the LAN via the I-Data 7913 Printer LAN attachment, such as an IBM 3812/16, IBM 3912/16, IBM 3112/16, IBM 4028, IBM 4230 or IBM 6400. Note: The IBM 4224 and 4324 (IPDS model) are not supported.
IPDS LAN-attached printers must be configured AFP(*YES), and Print Services Facility/400 (PSF/400) is required.
LAN-attached printers using the LexLink protocol. OS/400 V3R1 added support for the Lexmark LexLink protocol allowing ASCII printers to be directly attached to the LAN. With this protocol, the printer must have a Lexmark INA (Internal Network Adapter) card, or be attached to the LAN using a Lexmark MarkNet XLe connection. Almost all ASCII printers are supported, such as IBM Network Printers, Lexmark Optra, HP III, HP 4, etc. Note: The printer must be on the same LAN segment as the AS/400 if the LAN segments are interconnected using routers (LexLink is not a routable protocol, it must be bridged).
LAN-attached ASCII printers using a PJL (Printer Job Language) driver. At OS/400 V3R7 support was added for two new system drivers (*IBMPJLDRV and *HPPJLDRV) allowing ASCII printers to be LAN attached without using the LexLink protocol. The *IBMJLDRV driver supports all IBM printers (for example, the IBM 4039 plus, 4312, 4317 and 4324) attached with a LAN card and using TCP/IP. The *HPPJLDRV driver supports all HP and HP compatible printers (for example, the HP IIIsi, HP 4 and HP 5) attached using an HP JetDirect or compatible card or box using TCP/IP. Notes: 1. The printer and LAN attachment card or box must support PJL. 2. These new drivers are not supported by OS/400 V3R2.
For detailed information and configuration examples for LAN-attached IPDS and ASCII printers, refer to the redbook AS/400 Printing V , SG24-2160.
551
Type Connection to Printer Data Stream of Printer Support Printer Attached to Link Network ASCII SCS AFPDS /IPDS ASCII INA, LAN LexLink yes yes 1 yes 2 MarkNet ASCII LAN card LAN TCP/IP yes yes 1 yes 2 ASCII PSF Direct, LAN SNA yes yes PSF/2 DPF IPDS PSF Direct, LAN SNA yes yes PSF/2 DPF IPDS AFCCU, LAN TCP/IP yes yes LAN card, I-Data 7913
Notes:
1 The conversion from SCS to ASCII is performed by the OS/400 host print transform function. 2 The conversion from AFPDS to ASCII is performed by the OS/400 host print transform function. The IPDS data stream cannot be transformed by the host print transform.
552
18.5.3 Printers Attached to Workstations

PCs and InfoWindow displays can have directly attached ASCII printers. The AS/400 spooled files must be transformed into ASCII printer data streams. The following transformation methods are available:
Using the InfoWindow emulator. Only SCS data streams are supported. Transform tables can be customized. Using PC5250 transform based on a Printer Definition Table (PDT). Only SCS data streams are supported. Customization is possible. Using a PC5250 transform based printer driver. Only SCS data streams are supported. No customization is possible. Using the host print transform function. SCS and AFPDS data streams are supported. The WSCST (Workstation Customized) object can be customized.
AS/400 LAN Twinax ASCII or WSC WSC WAN Adapter Local or CA Remote CA /400 /400 ASCII ASCII Printer Printer CA Apple /400 Mac ASCII ASCII Printer Printer CP /400 ASCII Printer RS/6000
Figure 507. Printers Attached to Workstations
553
Type Connection to Printer Data Stream of Printer Support Printer Attached to Link Network ASCII SCS AFPDS /IPDS ASCII Client direct, SNA yes yes 1 yes 2 Access/400 LAN/WAN ASCII Apple Mac LAN/WAN AppleTalk, yes yes 1 yes 2 SNA, TCP/IP ASCII Connection LAN/WAN SNA, yes yes 1 yes 2 Program/400 TCP/IP
Note:
1 Conversion from SCS to ASCII by a PC based emulator or by the OS/400 host print transform function. 2 Conversion from AFPDS to ASCII by the OS/400 host print transform function. IPDS data streams cannot be transformed.
554
18.5.4 PSF/2, PSF/6000 and AS/400

PSF/2 and PSF/6000 are LAN print server programs. PSF/2 runs on an OS/2 system and PSF/6000 runs on an RS/6000 system. They support the spooling and conversion of AFPDS to ASCII printer data streams and IPDS data streams. The AS/400 sends the spooled files by using remote system printing. For detailed information on remote system printing, refer to the redbook AS/400 Printing IV , GG24-4389. AS/400 PSF/2 Coax IPDS Printer, e.g. IBM 3916 Channel IPDS Printer, e.g. IBM 3835 AFPDS, ASCII LPR/ ASCII Printers, PPDS or PCL4/5 LPD TCP/IP PPDS or PCL4/5 via LexLink or TCP/IP, Ethernet or TokenRing IPDS via TCP/IP, MarkNet ASCII Printers, TokenRing or XLe PPDS or Ethernet PCL4, PCL5 idata Twinax or 791X Coax IPDS Printers AFPDS, ASCII PSF TCP/IP /6000 Channel IPDS Printers ASCII Printers, PPDS or PCL4/5 see PSF/2
Figure 508. PSF/2, PSF/6000 and AS/400
PSF/2 converts the following:

AFPDS to IPDS IPDS to PCL4, PCL5, PPDS PostScript to IPDS
PSF/6000 converts the following:
AFPDS to PCL4, PCL5, PPDS
555
PostScript to IPDS
Type Connection to Printer Data Stream of Printer Support Printer Attached to Link Network ASCII SCS AFPDS /IPDS IPDS 1 PSF/2 LAN/WAN TCP/IP yes yes 2 ASCII 3 PSF/2 LAN/WAN TCP/IP yes yes 4 yes 5 IPDS PSF/6000 LAN/WAN TCP/IP yes yes 6 ASCII PSF/6000 LAN/WAN TCP/IP yes yes 4 yes 5
Notes:
1 This is any IPDS printer directly attached to PSF/2 or connected via I-data. 2 An IPDS spooled file cannot be sent to PSF/2. Use PSF Direct or PSF/2 DPF in place of remote system printing, or change the printer device type parameter in the printer file to *AFPDS. 3 This is any ASCII printer directly attached to PSF/2 or connected via MarkNet XLe. 4 Transformation from SCS to ASCII by the host print transform function. 5 Transformation from AFPDS to ASCII by the OS/400 host print transform function. IPDS spooled files cannot be transformed. 6 An IPDS spooled file cannot be sent to PSF/6000. Use PSF Direct in place of remote system printing, or change the printer device type parameter in the printer file to *AFPDS.
MarkNet XLe supports up to three PC printers (two parallel and one serial) via LexLink (802.2), TCP/IP or IPX. i-data (IBM 731X) supports up to two printers but only one active printer at a time.
556
18.5.5 Print Output to Printers Controlled by Other Systems

The AS/400 as a print requester can forward print output to other systems using facilities like TCP/IP LPR, SNA/DS Object Distribution Facility (ODF) or Network Job Entry (NJE). AS/400 Application or Print Requester JES/MVS RSCS/VM TCP/IP LPD OS/400 ODF
Figure 509. Print Output Transfer to Other Systems
Type Connection to Printer Data Stream of Printer Support Printer AS/400 Link Network ASCII SCS IPDS AFPDS transfers ASCII as LAN/WAN TCP/IP yes yes 1 yes 2 TCP/IP LPR IPDS using LAN/WAN SNA yes yes yes SNADS/ODF IPDS using NJE LAN/WAN SNA yes yes 3 yes VM/MVS Bridge
557
Notes:
1 This is the conversion from SCS to ASCII performed by the OS/400 Host Print Transform function. 2 Transformation from AFPDS to ASCII by the OS/400 host print transform function. 3 IPDS data cannot be sent if any special device requirements are present such as fonts, bar codes rotation, or graphics. You can send the data by copying the spooled file to a database file ( CPYSPLF command) and then using the SNDNETF command to send it as a network file.
With OS/400 V3R1, the Remote System Printing function allows spooled files to be automatically sent to other systems.
558
Appendix A. Special Notices

This publication is intended to help customers and systems engineers understand multiprotocol networking and how the AS/400 fits into this world. The information in this publication is not intended as the specification of any programming interfaces that are provided by Operating System/400. See the PUBLICATIONS section of the IBM Programming Announcement for Operating System/400 for more information about what publications are considered to be product documentation. References in this publication to IBM products, programs or services do not imply that IBM intends to make these available in all countries in which IBM operates. Any reference to an IBM product, program, or service is not intended to state or imply that only IBM s product, program, or service may be used. Any functionally equivalent program that does not infringe any of IBM s intellectual property rights may be used instead of the IBM product, program or service. Information in this book was developed in conjunction with use of the equipment specified, and is limited in application to those specific hardware and software products and levels. IBM may have this document. these patents. Licensing, IBM patents or pending patent applications covering subject matter in The furnishing of this document does not give you any license to You can send license inquiries, in writing, to the IBM Director of Corporation, North Castle Drive, Armonk, NY 10504-1785.
Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact IBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA. Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The information contained in this document has not been submitted to any formal IBM test and is distributed AS IS. The information about non-IBM ( vendor ) products in this manual has been supplied by the vendor and IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a customer responsibility and depends on the customer s ability to evaluate and integrate them into the customer s operational environment. While each item may have been reviewed by IBM for accuracy in a specific situation, there is no guarantee that the same or similar results will be obtained elsewhere. Customers attempting to adapt these techniques to their own environments do so at their own risk. Any pointers in this publication to external Web sites are provided for convenience only and do not in any manner serve as an endorsement of these Web sites. Any performance data contained in this document was determined in a controlled environment, and therefore, the results that may be obtained in other
559
operating environments may vary significantly. Users of this document should verify the applicable data for their specific environment. Reference to PTF numbers that have not been released through the normal distribution process does not imply general availability. The purpose of including these reference numbers is to alert IBM customers to specific information relative to the implementation of the PTF when it becomes available to each customer according to the normal IBM PTF distribution process. The following terms are trademarks of the International Business Machines Corporation in the United States and/or other countries:
Advanced Function Printing AFP AnyNet AS/400 DRDA ESCON InfoPrint Intelligent Printer Data Stream Network Station OfficeVision/400 Operating System/2 OS/400 RS/6000 SQL/DS System/390 400 AFCCU AIX APPN DB2 eNetwork IBM InfoWindow IPDS Nways Operating System/400 OS/2 Print Services Facility S/390 System/36 VTAM
The following terms are trademarks of other companies: C-bus is a trademark of Corollary, Inc. Java and HotJava are trademarks of Sun Microsystems, Incorporated. Microsoft, Windows, Windows NT, and the Windows 95 logo are trademarks or registered trademarks of Microsoft Corporation. PC Direct is a trademark of Ziff Communications Company and is used by IBM Corporation under license. Pentium, MMX, ProShare, LANDesk, and ActionMedia are trademarks or registered trademarks of Intel Corporation in the U.S. and other countries. UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company Limited. Other company, product, and service names may be trademarks or service marks of others.
560
Appendix B. Related Publications

The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this redbook.
B.1 International Technical Support Organization Publications

For information on ordering these ITSO publications see How to Get ITSO Redbooks on page 563.

AS/400 AnyNet Scenarios, SG24-2531 IBM AS/400 Printing IV , GG24-4389 IBM AS/400 Printing V , SG24-2160 IBM 2210 Nways Multiprotocol Router Description and Configuration Scenarios, SG24-4446 Using the AS/400 as an IPX Router, SG24-4736 Inside APPN - The Essential Guide to the Next-Generation SNA , SG24-3669
B.2 Redbooks on CD-ROMs

Redbooks are also available on CD-ROMs. Order a subscription and receive updates 2-4 times a year at significant savings.
CD-ROM Title System/390 Redbooks Collection Networking and Systems Management Redbooks Collection Transaction Processing and Data Management Redbook Lotus Redbooks Collection Tivoli Redbooks Collection AS/400 Redbooks Collection RS/6000 Redbooks Collection (HTML, BkMgr) RS/6000 Redbooks Collection (PostScript) RS/6000 Redbooks Collection (PDF Format) Application Development Redbooks Collection Subscription Number SBOF-7201 SBOF-7370 SBOF-7240 SBOF-6899 SBOF-6898 SBOF-7270 SBOF-7230 SBOF-7205 SBOF-8700 SBOF-7290 Collection Kit Number SK2T-2177 SK2T-6022 SK2T-8038 SK2T-8039 SK2T-8044 SK2T-2849 SK2T-8040 SK2T-8041 SK2T-8043 SK2T-8037
B.3 Other Publications

These publications are also relevant as further information sources:

AS/400 TCP/IP Configuration and Reference, SC41-3420 IBM 6611 Introduction and Planning Guide, GK2T-0334 IBM 5394 Remote Control Unit, T2.1 Support RPQ 8Q0775, SC30-3531 IBM Multiprotocol Network Program Configuration Guide, SC31-6691 IBM Multiprotocol Network Program Operations and Problem Management, SC31-6692 IBM 2210 Nways Multiprotocol Introduction and Planning Guide, GA27-4068 IBM 2210 Nways Multiprotocol Router Network Services Software User s Guide, SC30-3681
561
IBM 2210 Nways Multiprotocol Router Network Services Protocol Configuration and Monitoring Reference, SC30-3680 IBM 2217 Nways Multiprotocol Concentrator User s Guide , GC30-3706 Configuration Program User s Guide for Nways Multiprotocol and Access Services Products , GC30-3830
562
How to Get ITSO Redbooks

This section explains how both customers and IBM employees can find out about ITSO redbooks, redpieces, and CD-ROMs. A form for ordering books and CD-ROMs by fax or e-mail is also provided.
Redbooks Web Site http://www.redbooks.ibm.com/ Search for, view, download or order hardcopy/CD-ROMs redbooks from the redbooks Web site. Also read redpieces and download additional materials (code samples or diskette/CD-ROM images) from this redbooks site. Redpieces are redbooks in progress; not all redbooks become redpieces and sometimes just a few chapters will be published this way. The intent is to get the information out much quicker than the formal publishing process allows.
E-mail Orders Send orders via e-mail including information from the redbook order form to:
IBMMAIL usib6fpl at ibmmail caibmbkz at ibmmail dkibmbsh at ibmmail Internet usib6fpl@ibmmail.com lmannix@vnet.ibm.com bookshop@dk.ibm.com
In United States: I n Canada: Outside North America:
Telephone Orders
United States (toll free) Canada (toll free) Outside North America (+45) 4810-1320 - Danish (+45) 4810-1420 - Dutch (+45) 4810-1540 - English (+45) 4810-1670 - Finnish 1-800-879-2755 1-800-IBM-4YOU (long (+45) (+45) (+45) distance charges apply) 4810-1220 - French 4810-1020 - German 4810-1620 - Italian
(+45) 4810-1270 - Norwegian (+45) 4810-1120 - Spanish (+45) 4810-1170 - Swedish
This information was current at the time of publication, but is continually subject to change. The latest information for customers may be found at http://www.redbooks.ibm.com/ and for IBM employees at http://w3.itso.ibm.com/. IBM Intranet for Employees IBM employees may register for information on workshops, residencies, and redbooks by accessing the IBM Intranet Web site at http://w3.itso.ibm.com/ and clicking the ITSO Mailing List button. Look in the Materials repository for workshops, presentations, papers, and Web pages developed and written by the ITSO technical professionals; click the Additional Materials button. Employees may also view redbook, residency and workshop announcements at http://inews.ibm.com/.
563
IBM Redbook Fax Order Form

Fax your redbook orders to:
United States (toll free) Canada Outside North America 1-800-445-9269 1-403-267-4455 (+45) 48 14 2207 (long distance charge)
Please send me the following:

Title Order Number Quantity
First name Company Address City Telephone number Invoice to customer number Credit card number
Last name
Postal code Telefax number
Country VAT number
Credit card expiration date
Card issued to
Signature
We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not available in all countries. Signature mandatory for credit card payment.
564
Index Numerics
2210 2216 3270 5250 5394 5494 Nways Multiprotocol Router 47, 75 Nways Multiaccess Connector 45 Emulation 56 Passthrough 56 Remote Workstation Controller 75 Remote Workstation Controller 3 Discovery frame 20 Discovery response frame 21 DLSw 531 DNS (Domain Name System) 58 Domain Name See NetBIOS (Network Basic Input/Output System), Domain Name DRDA (Distributed Relational Database Access) 56 DSPT (Display Station Passthrough) See 5250 Passthrough
A
Advanced Function Printing Data Stream (AFPDS) 545 All-routes broadcast 21 AppleTalk 29 APPN (Advanced Peer-to-Peer Networking) end node (EN) 10 Low entry networking (LEN) node 10 network node (NN) 10 ARP 524
E
eNetwork Communications Server V4.2.1 9, 29, 43 7
F
Filtering database 19, 22 Flow control 39 Forwarding table 19 Frame relay 17 FTP (File Transfer Protocol)
B
Backup 517 Bandwidth 523 Bandwidth Reservation (BRS) 526, 535 bibliography 561 BOOTP (Bootstrap Protocol) 57 Boundary Access Node (BAN) 40 Bridge number 21 Bridging 18
7, 57
H
High Performance Routing (HPR) 11 Hops count 21 Host Print Transform function 552
I
IBM PC/3270 7 Integrated PC Server (IPCS) 53 Intelligent Printer Data Stream (IPDS) 545 Internet Connection Server 58 IPX (Internetwork Packet eXchange) 4, 15, 29, 59 ISDN 518
C
Carrier Sense Multiple Access/Collision Detect (CSMA/CD) 17 Class of Service (COS) 37 Class of Service (COS) description 62 Client Access/400 7, 56 Compression 524 Congestion 39, 523 Connection-oriented 6 Connectionless 6 Controller description 61
L
LAN Manager 7 LAN Server 7 Line description 61 Local location list 61 Logical Link Control (LLC) 17 Lotus CC: Mail 7 Lotus Notes 7 LPD/LPR (Line Print Requestor / Line Print Daemon) 546 LPD/LPR (Line Print Requestor/Line Print Daemon) 57 57
D
data link switching (DLSw) 34 DDM (Distributed Data Management) 56 DEC LAT 29 DECet 29 Device description 61 DHCP (Dynamic Host Configuration Protocol) Dial on Demand 529
565
M
MAC Filtering (MCF) 527 MAC sublayer 19 Machine name See NetBIOS (Network Basic Input/Output System), Machine Name Maximum frame size 21 Media Access Control (MAC) 17 Mode description 62 Multi Function I/O Processor (MFIOP) 52
S
SDLC 17 SDLC Relay 75 SDLC Support 41 Segment number 21 Serial Tunnelling See SDLC Support Shielded twisted pair (STP) 17 Single route broadcast 20 Six Line Communications Controller (SLCC) 53 SMTP (Simple Mail Transport Protocol) 7, 57 SNA (Systems Network Architecture) 4 SNA Character Stream (SCS) 545 SNA Circuit pacing 525 SNA node type 2.1 9 SNA Pacing window 525 SNA Primary LU Support (SPLS) 56 SNADS (SNA Distribution Services) 56 SNMP (Simple Network Management Protocol) 7, 58, 539 Source route - translational bridge (SR-TB) 23 Source route bridge (SRB) 19, 20 All-routes broadcast 21 Bridge number 21 Discovery frame 20 Discovery response frame 21 Hops count 21 Maximum frame size 21 Routing information field (RIF) 21 Routing Information Indicator (RII) 21 Segment number 21 Single route broadcast 20 Token-ring LAN 20 Token-ring spanning tree algorithm 21 Source route transparent bridge (SRT) 19, 22 Filtering database 22 Routing information field (RIF) 22 Routing information indicator (RII) 22 Source Route Bridge (SRB) 22 Transparent Bridge (STB) 22 Source route-translational bridge (SR-TB) 19 Ethernet LAN 23 Routing information indicator (RII) 24 Source Route Bridge (SRB) 23 Token-ring LAN 23 Transparent Bridge (STB) 23 Spanning tree bridge (STB) 19 Spanning tree bridging (STB) 19 See also Transparent Bridge (STB) Spanning tree protocol 20 SPX 15 SR-TB See Source route transparent bridge (SRT) SRB See source route bridge (SRB) SRT See Source route transparent bridge (SRT)
N
NetBIOS (Network Basic Input/Output System) 29, 59 Domain Name 16 Machine Name 16 NetBIOS filtering 531 NetBIOS name caching 531 NetWare 4, 7 Network interface 61 Network Management 537 Network Monitoring 537 NFS (Network File System) 7 16,
O
OSI 58 OSPF (Open Shortest Path First) 33
P
PCI LAN/WAN/Workstation Input Output Processor (IOP) 52 Performance 523 Point-to-point Protocol (PPP) 17 POP (Post Office Protocol) 58 Printing 541 Prioritization 524 PSF/2 555 PSF/6000 555 PU Types 2.0 42
R
REXEC (Remote Execution) 58 RFC 1490 40 RIP (Routing Information Protocol) 33 RJE (Remote Job Entry) 57 RouteD (Route Deamon) 58 Router Configuration 537 Router Maintenance 537 Router Operation 537 Router Problem Determination 537 Routing information field (RIF) 21, 22 Routing information indicator (RII) 21, 22, 24
566
SSCP 9 STB See Transparent Bridge (STB) Subarea SNA 29 System/36 75
T
TCP/IP 4, 14, 29 TELNET 7, 57 Token-ring LAN 20 Token-ring spanning tree algorithm Transparent Bridge (STB) 19 Filtering database 19 Forwarding table 19 MAC sublayer 19 Spanning tree bridge (STB) 19 Spanning tree protocol 20 Transparent Bridge process 20 Transparent Bridge process 20 21
U
UNIX 4 Unshielded twisted pair (UTP) 17
V
Vines 29 VM/MVS Bridge 56, 546
W
WAN (Wide Area Network) WAN Restoral (WRS) 528 5
X
XNS 29
Index
567
568
ITSO Redbook Evaluation

AS/400 in Multiprotocol Networks SG24-4522-01 Your feedback is very important to help us maintain the quality of ITSO redbooks. Please complete this questionnaire and fax it to: USA International Access Code + 1 914 432 8264 or:

Use the online evaluation form found at http://www.redbooks.ibm.com Send your comments in an Internet note to redbook@us.ibm.com
Which of the following best describes you? __Customer __Business Partner __Solution Developer __None of the above
__IBM employee
Please rate your overall satisfaction with this book using the scale: (1 = very good, 2 = good, 3 = average, 4 = poor, 5 = very poor) Overall Satisfaction ____________
Please answer the following questions:

Was this redbook published in time for your needs? Yes____ No____
If no, please explain: _____________________________________________________________________________________________________ _____________________________________________________________________________________________________ _____________________________________________________________________________________________________ _____________________________________________________________________________________________________
What other redbooks would you like to see published? _____________________________________________________________________________________________________ _____________________________________________________________________________________________________ _____________________________________________________________________________________________________
Comments/Suggestions: (THANK YOU FOR YOUR FEEDBACK!) _____________________________________________________________________________________________________ _____________________________________________________________________________________________________ _____________________________________________________________________________________________________ _____________________________________________________________________________________________________ _____________________________________________________________________________________________________
569
SG24-4522-01
SG24-4522-01 Printed in the U.S.A.
IBM

AS400 Multiprotocol

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

AS400 Multiprotocol

Enviado por

Direitos autorais:

Formatos disponíveis

IBM

AS/400 in Multiprotocol Networks

International Technical Support Organization http://www.redbooks.ibm.com

International Technical Support Organization AS/400 in Multiprotocol Networks January 1999

Second Edition (January 1999)

Part 1. Part 1 - Introduction

Part 2. Part 2 - Router Scenarios

85 85 . 87 . 87 . 89 . 91 100 111 117 118 119 119

AS/400 in Multiprotocol Networks

11.6 Starting and 11.6.1 Starting 11.6.2 Starting 11.6.3 Starting

Verifying the and Verifying and Verifying and Verifying

AS/400 in Multiprotocol Networks

Part 3. Additional Considerations

Appendix A. Special Notices

559 561 561 561 561 563 564 565 567

ITSO Redbook Evaluation

AS/400 in Multiprotocol Networks

The Team That Wrote This Redbook

Copyright IBM Corp. 1996 1999

AS/400 in Multiprotocol Networks

Part 1. Part 1 - Introduction

Copyright IBM Corp. 1996 1999

AS/400 in Multiprotocol Networks

Chapter 1. Why Multiprotocol Networks

Figure 1. Classic AS/400 Networking Environment

Copyright IBM Corp. 1996 1999

1.1 How Multiple Protocols Arise

Figure 2. Different Applications Require Different Protocols

AS/400 in Multiprotocol Networks

1.2 Multiprotocol Networks Using Routers

Figure 3. Multiprotocol Router Network with AS/400 and I B M 5494

Chapter 1. Why Multiprotocol Networks

1.2.1 What Are Routers?

1.2.2 Benefits of Routers

AS/400 in Multiprotocol Networks

Chapter 2. Networking Technologies

Protocols Bridging and routing Routable and non-routable protocols

2.1 Why Different Protocols?

Copyright IBM Corp. 1996 1999

2.2 SNA (Systems Network Architecture)

AS/400 in Multiprotocol Networks

2.2.1 Subarea SNA

Figure 4. Subarea SNA Topology

2.2.2 APPN (Advanced Peer-to-Peer Networking)

Chapter 2. Networking Technologies

Figure 5. APPN Network Topology

APPN offers the following advantages over an SNA subarea network:

APPN defines the following three types of nodes within a network:

Local resources owned by the node

AS/400 in Multiprotocol Networks

2.2.3 High Performance Routing

Rapid-Transport Protocol (RTP) Automatic Network Routing (ANR)

Chapter 2. Networking Technologies

Figure 6. An RTP Connection in an HPR Subnet within an APPN Network

2.2.4 Rapid Transport Protocol (RTP)

AS/400 in Multiprotocol Networks

2.2.4.2 Network Layer Packets (NLPs)

Figure 7. Possible Link Frames in an HPR Node

2.2.4.3 End-to-End Error Recovery

Chapter 2. Networking Technologies

2.2.4.4 Non-Disruptive Path Switching

2.2.5 Automatic Network Routing (ANR)