As Client Access specialists for the AS/400, we must keep up with all the capabilities of our system’s 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. I’ll walk you through the entire scope of IPX as it’s implemented on the AS/400—from Integrated PC Server (IPCS) to IPX routing. When you’re through reading, you’ll 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 isn’t 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 IPX—such 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/400’s AnyNet/400 feature. NCP isn’t provided by OS/400; it’s 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/400’s 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) or—surprisingly—as 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. Let’s look at both issues briefly. Because the IPCS is controversial, I’ll try not to prejudice this examination with my opinion. As Client Access specialists, you’ll 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/400’s 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.

IBM’s stated purpose for IPCS is to coordinate the services of a LAN file server with the resources of the AS/400’s 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 isn’t 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 valid—if slightly paranoid and shallow—perspective of the IPCS’s 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. It’s 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 Novell’s NetWare as the NOS for the IPCS.

IPCS Network Operating Systems

The IPCS currently supports two separate NOSs: IBM’s LAN Server/400 (an adaptation of OS/2 LAN Server) and Novell’s 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 don’t understand it. So I’ll 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/400’s 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 IBM’s 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 don’t need an IPCS to implement routing, but you do need an AS/400 LAN interface. If your system doesn’t 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, and—attached to each AS/400—a 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 network’s 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/400’s System Name as the value for IPX Description Name. The internal network number is a unique hex number between 1 and FFFFFFFE, and it’s 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 you’re 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. I’ll 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 provider’s network administrator: He’ll 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 it’s 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, it’s *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/400’s 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 you’ve 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 WAN’s virtual circuits. To do this, create a Circuit Route—or, in Novell terminology, a Static Routing Table—using 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: specifies—in 1/18th of a second—the 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 don’t 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. It’s 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, it’s the circuit number of the X.25 line.

Service name: identifies the name of the service available on the remote system. In the example, it’s the print server’s name.

Service type: specifies the type of service available on the remote system. In the example, it’s *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 doesn’t have an internal network number—such as a NetWare 2 file server—use 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. It’s a two-byte hex value ranging from 0001 to FFFF. You’ll 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 you’ve 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 here—such as routing IP over IPX and IPX sockets programming—that ought to provide you with some interesting new tools for networking to your clients.

And don’t 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