As Client Access specialists for the AS/400, we must keep up with all the capabilities of our systems architecture. IBM continues to deliver new and enhanced features to the AS/400. One of the most surprising has been Novell IPX support.
This article takes a comprehensive look at what that support really means. Ill walk you through the entire scope of IPX as its implemented on the AS/400from Integrated PC Server (IPCS) to IPX routing. When youre through reading, youll understand that what IBM has delivered goes far beyond the confusion and hype about the IPCS and provides new tools that can significantly increase the services we offer our users.
IPX Support on the AS/400
Last year, IBM created IPX support for V3R1 of OS/400. IPX support isnt a simple subject. IPX means many different things to technical people. To NetWare enthusiasts, IPX is synonymous with the NetWare Network Operating System (NOS). To network administrators, IPX is just one of many underlying communications protocols within the network layer implemented by Novell. To the AS/400 specialist, IPX means something different still.
IPX support within OS/400 implements most of the NetWare protocol suite:
Sequenced Packet Exchange (SPX)
Internetwork Packet Exchange (IPX)
Routing Information Protocol (RIP)
Service Advertising Protocol (SAP)
NetWare Link Services Protocol (NLSP) Upper protocol layers that are normally considered part of IPXsuch as the Simple Network Management Protocol (SNMP), Sockets API, and NetWare Core Protocol (NCP)are provided on the AS/400 through other means.
For instance, SNMP is a standard OS/400 system management application, so it comes automatically with V3R1. By the same token, the Sockets API is a part of OS/400s AnyNet/400 feature. NCP isnt provided by OS/400; its available indirectly through the NetWare NOS when NetWare is loaded on the IPCS or File Server I/O Processor (FSIOP).
IPX support is best described as a licensed program feature that complements OS/400s participation in a Novell NetWare network. It provides the means by which an AS/400 can serve as a NetWare file server (using the IPCS) orsurprisinglyas an IPX router between two or more NetWare IPX networks.
Why IPX on the AS/400?
There are two primary reasons an AS/400 specialist might want IPX support on the AS/400. The first is the highly controversial implementation of the IPCS as a NetWare file server. The second is the advantages of IPX routing for the AS/400. Lets look at both issues briefly. Because the IPCS is controversial, Ill try not to prejudice this examination with my opinion. As Client Access specialists, youll have your own views anyway.
The IPCS and IPX: Reality Is in the Eye of the Beholder
The IPCS, previously known as the FSIOP, is an I/O card that slips into the AS/400s chassis. It contains an Intel 66MHz 486 microprocessor; an Intel I960 processor that communicates with the AS/400 System Bus; and up to two integrated, high- performance LAN adapters that support either Ethernet or token-ring protocols. The IPCS also houses up to 64MB of RAM for cache.
IBMs stated purpose for IPCS is to coordinate the services of a LAN file server with the resources of the AS/400s DASD. When a PC client on the LAN requests a file from the IPCS, the resident NOS searches for the file in its cache. If the file isnt present, the NOS communicates with OS/400, which locates the file and passes it along to the IPCS. The NOS then delivers the file to the requesting client.
Many reputable LAN specialists view the IPCS as a plot by IBM to force the AS/400 on the LAN community. They see the IPCS as an engineered kludge that shoves a nominal 486 into the gut of the AS/400 to drain expensive DASD while providing limited, patched-together file-serving services to the user community. This is a validif slightly paranoid and shallowperspective of the IPCSs function and capabilities. Of course, this conspiracy theory will probably last as long as IBM markets unique hardware solutions.
Other equally reputable LAN specialists see the IPCS as an intelligent I/O controller card that uses proven software resources to attach the AS/400 to the very different architecture of the PC LAN. In this light, the IPCS is no different from a distributed disk controller, a small computer system interface (SCSI) communications controller, or even an attached PC. Its a distributed processor that has its hooks buried deeply in the OS/400 operating system.
From either perspective, the IPCS is a formidable engineering feat that has added some high performance file serving and exceptional resiliency to the task of interfacing the AS/400 to previously established PC LANs. This is especially true now that IBM supports Novells NetWare as the NOS for the IPCS.
IPCS Network Operating Systems
The IPCS currently supports two separate NOSs: IBMs LAN Server/400 (an adaptation of OS/2 LAN Server) and Novells NetWare 4.1. There have been substantiated
rumors that Microsoft and IBM are working together to bring Windows NT to the IPCS. Once again, this is a highly controversial topic with its own pluses and minuses.
Why is the IPCS important to understanding IPX on the AS/400? Most significantly, the engineering task of placing NetWare 4.1 on the IPCS forced IBM to make the IPX suite of protocols available to the OS/400 operating system.
In particular, when NetWare is used as the resident NOS of the IPCS, IPX is the transmission protocol the NOS uses to communicate between OS/400 and the IPCS. In other words, NetWare talks to OS/400 on a peer-to-peer basis, exchanging IPX packets, just as it might communicate to a client or another server on the LAN.
Routing IPX on a WAN
This leads us to the second reason an AS/400 site might choose to implement IPX: IPX routing between LANs and WANs! AS/400 marketing types rarely discuss the AS/400 IPX routing capability, probably because they dont understand it. So Ill describe this capability in very specific terms.
Even if an IPCS FSIOP is not implemented on the AS/400, the same IPX peer-to- peer services that allow OS/400 to communicate with NetWare can be used to route IPX between networks to create a WAN.
There are a lot of advantages to this type of communication and routing, especially for shops in which NetWare is already established. For instance, one of the AS/400s major success stories is corporate electronic data interchange (EDI), which allows customers and vendors to interchange transactions across an X.25 communications network. Often these organizations have multiple AS/400s located at remote sites, each attached to a local NetWare LAN through Ethernet or token-ring.
Using IPX support for OS/400, these separate LANs can be joined into a WAN, with each AS/400 officiating as a router at the edge of the X.25 network. This means that a NetWare client on a LAN in New York could map a drive to a NetWare server in California. AS/400s on either side of the X.25 sea route the requests and transmit the packets between the separate NetWare LANs. A picture of this scenario is shown in Figure 1.
From a management perspective, this has the advantage of creating a new service by using the existing infrastructure of AS/400s. Meanwhile, the added cost is almost imperceptible. From a technical perspective, using the AS/400 as a router provides an interesting challenge.
What You Need for IPX Routing Support
To implement IPX routing on the AS/400, you need IBMs Network Extensions program feature (product number 5733-SA1). This product provides the OS/400 objects and online information you need to implement IPX routing. If your site already implements the IPCS as a NetWare server, Network Extensions should be loaded on your system. (You can use option 10 of the GO LICPGM command to verify this.) You dont need an IPCS to implement routing, but you do need an AS/400 LAN interface. If your system doesnt already have an Ethernet or token-ring card, you might consider using the IPCS as the LAN interface.
Five Steps to Configuring IPX for WAN Routing
Figure 1 portrays the architecture of the example WAN. It shows two AS/400s separated by an X.25 network, andattached to each AS/400a NetWare LAN
composed of servers, a client on one end, and a printer on the other. The proposed configuration is the connection to route from the New York client to the California printer.
The steps to configure this IPX route on the AS/400 are pretty straightforward.
1. Create an IPX description on each AS/400.
2. Configure an X.25 communications line description for each machine.
3. Add appropriate IPX circuit definitions.
4. Add required routing information.
5. Add service information. Each step requires that you use an OS/400 command. Most of the commands are specific to the OS/400 IPX support.
Create IPX Description (CRTIPXD)
Each AS/400 must have an IPX description object that identifies the IPX networks global default values. You create this description using the OS/400 CRTIPXD command provided by the Network Extensions feature. The IPX description object that is created is the base upon which a hierarchy of other OS/400 IPX objects are built. There are two essential parameters associated with the CRTIPXD command: the IPX Description Name, and the internal IPX network number.
IBM suggests that you use the AS/400s System Name as the value for IPX Description Name. The internal network number is a unique hex number between 1 and FFFFFFFE, and its the address by which all adjacent IPX nodes will access this AS/400. You can specify *RANDOM and let the system define a number, but if youre already using NetWare, your network administrator probably has a number he would rather assign. The other parameters of the CRTIPXD command default to IBM-supplied values, which should suffice for most purposes.
Creating Communication Lines
You must create two communications lines at each AS/400 site: one for the LAN (either Ethernet or token-ring) and one for the X.25 communications line. Ill focus on creating the X.25 line.
Create Line X.25 (CRTLINX25)
Creating a line description for the X.25 line is similar to creating any communications line description: You need a Line Description name for the OS/400 object, a Resource Name to attach the object to the specific hardware resource, and values for the parameters that describe the configuration of the virtual communications circuit. To identify these values, you must study and coordinate the values of both AS/400 sites that are communicating. If you already have an X.25 line configured for EDI, you can use those values as guidelines for generating your IPX X.25 line description. Otherwise, you should bone up on the parameters by studying the OS/400 Internetwork Packet Exchange Support manual. You should also contact your X.25 service providers network administrator: Hell tell you how to define some of the following items, which are the essential parameters for creating an X.25 line:
Line Description: a unique name for the communications line. Resource Name: the name of the communications port to which the hardware is connected.
Logical Channel Identifier: a unique, hex, channel-identifying number for the virtual communications circuit.
Logical Channel Type: a value that identifies the type of virtual circuit. In this example, the channel type is *SVCBOTH to indicate that its a Switched Virtual Circuit (SVC) for both input and output.
Local Network Address: a unique address that identifies the AS/400 to the X.25 network. This is usually established by the X.25 network administrator.
Connection Initiation: a value that identifies how the communication will be initiated. In this example, its *LOCAL because this is a DTE-to-DTE connection.
Packet Size (both default and maximum): a number that specifies the size of the packets that the X.25 network will support. Again, the X.25 network administrator who manages the global network sets this size.
Add IPX Circuits (ADDIPXCCT)
In the previous step, you identified the AS/400 to the X.25 network by establishing an SVC. This means that when the local AS/400 chooses to connect to the AS/400 residing on the other end of the X.25 network, a virtual circuit will be established through which packets of information can flow.
The next step is to establish a local IPX circuit to connect to the local IPX network so that clients on the NetWare LAN can be routed to that distant shore. The ADDIPXCCT command mates the parameters of the X.25 line with those required by the local IPX network.
Like the virtual circuit described in the X.25 line, an IPX circuit is a logical path through which information moves between IPX nodes. For a LAN, the IPX circuit defines the point of attachment from the IPX protocol layer to the IPX network. For a WAN, it defines the path from the IPX protocol layer to a remote IPX node or system.
Some parameters uniquely identify the IPX circuit, and others tie it to the X.25 communications line.
Circuit Name: identifies the IPX circuit and must uniquely name this IPX circuit. Line Description: references the X.25 communications line name previously created by the CRTLINX25 command.
X.25 PVC Logical Channel ID: specifies the Logical Channel ID previously
identified in the CRTLINX25 command.
X.25 SVC Network Address: specifies the remote AS/400s X.25 network
address.
X.25 Default Packet Size: should match the default packet size noted in the
CRTLINX25 command.
Automatic Start: specifies whether this IPX circuit automatically starts up when IPX is initiated.
RIP State: identifies that Routing Information Protocol (RIP) is used for this virtual circuit. Generally, you specify *NO.
SAP State: specifies whether Service Advertising Protocol (SAP) is enabled. Generally, you specify *NO.
Add Circuit Route (ADDCCTRTE)
Once youve created the communications path from the IPX circuit to the X.25 virtual circuit, you must provide some mechanism by which nodes on the LAN can locate the remote IPX through the WANs virtual circuits. To do this, create a Circuit Routeor, in Novell terminology, a Static Routing Tableusing the ADDCCTRTE command. Each Circuit Route Information Object ties a remote IPX network node with a locally accessible IPX circuit.
For instance, the remote AS/400 has its own IPX network identifier that was created on that system with the CRTIPXD command. When you use the ADDCCTRTE command, you associate that remote IPX address with the IPX circuit you created.
By the same token, if a NetWare server is connected to that remote AS/400, it too will have its own IPX network identifier. To access that second node, you would need to pass through the remote AS/400 to locate this second IPX participant. Consequently, you would also need to create a second Circuit Route object.
These are the parameters required for the ADDCCTRTE command: Circuit Name: identifies the local IPX circuit attached to the X.25 line. Remote IPX network number: specifies the IPX network address of the target server.
Number of hops: specifies how many IPX systems the circuit is passing through. Number of ticks: specifiesin 1/18th of a secondthe amount of time it will take to access the remote IPX node.
Add Circuit Services (ADDCCTSRV)
The final command step to orchestrating this WAN is to identify the circuit services associated with the remote IPX printer server. For the LAN part of the configuration, IPX support uses SAP or the NetWare Link Services Protocol (NLSP) to coordinate information about the network servers and the addresses of those services. Normally, LAN services are broadcast using SAP broadcast packets. However, WAN on-demand circuits dont have the ability to use these broadcast services and, consequently, need some other way to find nodes on the opposite end of the X.25 network. This is accomplished with a static service circuit. Its essentially a routing map.
To create the circuit service to reach the printer in California, use the ADDCCTSRV command. You need seven critical pieces of information for parameters:
Circuit name: identifies the circuit from which the printer is reached. In the example, its the circuit number of the X.25 line.
Service name: identifies the name of the service available on the remote system. In the example, its the print servers name.
Service type: specifies the type of service available on the remote system. In the example, its *PRTQ.
Remote IPX network number: identifies the remote IPX network number where the service is found.
Remote node address: identifies the node address where the service resides. This parameter has some interesting nuances. If the service is on a NetWare 3.x or 4.x server or router, the service IPX node address should be 1. If the server or router doesnt have an internal network numbersuch as a NetWare 2 file serveruse the network interface card (NIC) or medium access control (MAC) address of the server adapter for the IPX node address.
Remote socket address: identifies the socket on which this service listens for requests. This is the socket address found on the remote system. Its a two-byte hex value ranging from 0001 to FFFF. Youll have to receive this information from the network administrator on the remote system.
Number of hops: specifies the number of routers that will be crossed in order to reach the network or system identified by the remote network number.
These steps complete the WAN configuration. Assuming youve attached the NetWare LANs correctly to the AS/400, you can type in the Start IPX (STRIPX) command and begin testing your circuits.
The Future of IPX on the AS/400
Where Novell and IBM will go with IPX on the AS/400 is still not clear. There are capabilities not covered heresuch as routing IP over IPX and IPX sockets programmingthat ought to provide you with some interesting new tools for networking to your clients.
And dont forget to look seriously at the IPCS as an IPX resource, too. IBM is giving us tools to propel the AS/400 into the 21st century and to service our clients in the most flexible manner possible. Despite all the hype and opinions to the contrary, no one can predict the future. IPX on the AS/400 may prove to be the most resilient resource we have to address that future.
Reference
OS/400 Internetwork Packet Exchange Support (SC41-3400).
Figure 1: Joining LANs with IPX
LATEST COMMENTS
MC Press Online