IP Channel Communications Program Configuration in Principle and Practice ========================================================================= Introduction ~~~~~~~~~~~~ The IP Channel Communications Program (IPCHAN, for short) is a software program that runs on the OS/2-based version of IBM's 3172 Model 3 channel- attached controller platform. It is designed to enable TCP/IP-capable workstations, attached to the 3172 via LAN (TR, E'net, FDDI & ATM) and WAN (Frame Relay) connections, to access mainframe-resident TCP/IP applications (Telnet and FTP, for example). Note that in the following discussion, the word "mainframe" is used in its normal sense and the word "host" is used to mean any TCP/IP-capable computer, which may include a mainframe but does not specifically mean a mainframe. Configuration in Principle ~~~~~~~~~~~~~~~~~~~~~~~~~~ The most applicable conceptual analogy to think of IPCHAN in terms of is as a virtual LAN. That is, when IPCHAN is used to connect a 3172 to one or more mainframes, it forms a virtual LAN to which the mainframe(s) and the 3172 are attached. This can be illustrated by comparing the following physical and logical views of a potential IPCHAN configuration: Physical View Logical View ------------- ------------ ___________ ___________ ___________ ___________ | | | | | | | | | Mainframe | | Mainframe | | Mainframe | | Mainframe | |___________| |___________| |___________| |___________| \\ // | | \\ // ___|_______________|___ \\ Channels // / \ \\ // | IPCHAN Virtual LAN | \\ // \_______________________/ \\ // | __\\___//__ _____|_____ | | | | | 3172-3 | | 3172-3 | |___________| |___________| | |____ | |____ _____|_____ / \ _____|_____ / \ | | | | | | | | E'net \____/ TR \____/ When assigning IP addresses to machines connected to a real LAN, it is a fundamental aspect of TCP/IP that the LAN is assigned a (sub-)network IP address and each machine that is connected to it is assigned that same (sub-)network IP address as the (sub-)network portion of its host IP address (with each host's "host" portion uniquely identifying that particular host on that particular network). The exact same fundamental approach to IP address allocation applies to machines being connected to an IPCHAN Virtual LAN. That is, all the mainframes and the 3172 that are "connected" to the IPCHAN Virtual LAN should all belong to the same IP (sub-)network (i.e. the (sub-)network portion of their IP addresses should all be identical). Using this standard approach to IP address allocation, we can assign some example IP addresses to the machines connected to the IPCHAN Virtual LAN in our logical view of the above IPCHAN configuration and to the 3172's real LAN connections, as well: ___________ ___________ | | | | | Mainframe | | Mainframe | |___________| |___________| 192.10.21.2 | | 192.10.21.3 ___|_______________|___ / \ | IPCHAN Virtual LAN | \_______________________/ | 192.10.21.1 _____|_____ | | | 3172-3 | |___________| 192.10.22.1 | |____ 192.10.23.1 _____|_____ / \ | | | | \____/ The above labelling, of course, implies the following assignment of (class C) network IP addresses to the LANs (both real and virtual): LAN Network IP Address -------------- ------------------ IPCHAN Virtual 192.10.21 Ethernet 192.10.22 Token-Ring 192.10.23 Note that each "connection" to the IPCHAN Virtual LAN gets its own IP address from the pool of available host IP addresses for that LAN (254 host IP addresses in the case of a non-subnetted class C IP network, as used in this example). So, what is, in reality, one channel link, can be thought of as having two IP addresses: one at the mainframe end of the channel and another at the 3172 end of the channel. When mulitple mainframes connect up to the one 3172, the same is true, just that all the channel connections converging at the 3172 have the same IP address (192.10.21.1 in this case) because the 3172 has a single "connection" to the IPCHAN Virtual LAN. For those who may be familiar with either the TCP/IP Offload or the ICP 3172 products, IPCHAN represents a different requirement for IP address configuration. In the case of both Offload and ICP, the IP address of the mainframe is the *same* as the IP address of the 3172's connection to a real LAN. This forcibly restricts the number of mainframe connections to one per 3172 LAN adapter. For instance, in the example we've been dealing with, the left-hand mainframe may map its home IP address (192.10.21.2) to the 3172's Ethernet LAN adapter and the right-hand mainframe may map its home IP address (192.10.21.3) to the 3172's Token-Ring LAN adapter and those LAN adapters would *not* have IP addresses of their own. In effect, each LAN adapter is tied directly to one mainframe and it acts as that mainframe's connection to that IP network. This difference in IP address configuration between Offload/ICP and IPCHAN is because of the effective number of IP layers involved in each case and the basic fact in IP networking that each connection of an IP layer to a network is assigned a unique host IP address. A brief statement can be made for each product: - For ICP, there is one IP layer only, namely the mainframe's. There is no IP layer in the 3172; the 3172 merely acts as a conduit for transporting LAN-based IP traffic up to the mainframe's IP layer for processing. Since the 3172's LAN adapter is effectively the mainframe's IP layer's LAN access provider, its IP address must be the same as the mainframe's home IP address for that IP connection. - For Offload, although there is an IP layer in both the mainframe and the 3172, the two IP layers collude to act as one IP layer with the intention being that the 3172's IP layer do as much of the work as possible, thus "offloading" work from the mainframe's IP layer. Since they wish to appear as one IP layer, they must share one IP address per network connection. So the home IP address at the mainframe is the same as the 3172's LAN adapter's IP address. - For IPCHAN, there are two, completely separate, IP layers at work: one in the mainframe and one in the 3172. The only interaction these two IP layers have is the same as that between any two IP layers in any two machines on an IP network; i.e. they send IP packets to one another. As a result, each IP layer's connection to a LAN (physical or logical) must be given its own unique host IP address. Though the virtual LAN analogy is extremely useful in understanding the IP address configuration requirements of the IPCHAN product, it is not fully applicable to IPCHAN in every possible sense; i.e. IPCHAN does not provide a complete LAN emulation environment. One aspect of true LAN emulation that IPCHAN does not fully support is that of broadcasting. With real LANs, a frame can be broadcast by a machine onto a given LAN segment in order to distribute the frame to every other machine on that segment. IPCHAN supports broadcasting in one "direction" only: namely, from the 3172 *to* the mainframes. That is, frames that the 3172's IP layer sends as broadcasts onto the IPCHAN Virtual LAN are sent to all the other devices (all the mainframes) by IPCHAN. However, broadcasts that originate from some other device on the IPCHAN Virtual LAN (i.e. any of the mainframes) are received only by the 3172's IP layer, not by the other mainframes' IP layers. The implication of this restriction is that the use of TCP/IP applications that utilize the broadcast services of LANs needs special consideration when IPCHAN is involved in an internet. An example of this is when the RIP dynamic routing protocol is to be used in an internet environment. RouteD (the implementation of RIP) broadcasts its routing advertisments on the network media in order to distribute them to other RouteD processes on other machines. Because of IPCHAN's broadcast restriction, as discussed above, routing advertisments generated by the mainframes' RouteD processes will reach the 3172's RouteD process only and not the RouteD processes of any of the other mainframes on the IPCHAN Virtual LAN. If RouteD ran in this manner without manual configuration intervention, any given mainframe would not learn about, and would therefore not use, the routes that exist to other mainframes (and any networks beyond those other mainframes) via the 3172. To avoid this problem, the RouteD servers in mainframes attached to an IPCHAN 3172 must have defined, in their ETC.GATEWAYS file, static routes to the other mainframes connected to the same IPCHAN Virtual LAN (and to any networks that are accessible via those same mainframes). Defining such static routes is the way, when using RIP, to cope with "passive" gateways (or routers), namely those from which RIP advertisments will not be received. When considered from the point of view of any one IPCHAN Virtual LAN-attached mainframe, all the other mainframes attached to that same IPCHAN Virtual LAN are, in effect, "passive" because no RIP advertisments are received from them. This is not because the other mainframes' RouteD servers don't send them, it's because IPCHAN's broadcast restriction prevents them from being received. Note that since broadcasts are supported from the 3172 *to* the mainframes, all the mainframes will learn about routes advertised by the 3172's RouteD server. That is, the 3172 is an "active", not a passive, gateway with respect to all the mainframes on an IPCHAN Virtual LAN. This means that definition of static routes in the mainframes' ETC.GATEWAYS files need not include routes to real LANs and WANs on the other side of the 3172; such routes will be learned from the 3172's RouteD server's RIP advertisments. Similarly, no definition of static routes to the IPCHAN Virtual LAN-attached mainframes is required for the RouteD server on the 3172, because it will receive all the mainframes' RouteD servers' RIP advertisments. That is, the mainframes are active, not passive, gateways from the 3172's point of view. Of course, if static, as opposed to dynamic, routing is to be used where IPCHAN is involved, the above discussion regarding RIP is irrelevant. Configuration in Practice ~~~~~~~~~~~~~~~~~~~~~~~~~ This section is intended to provide a different angle on the configuration of an IPCHAN environment to that provided by the IPCHAN User's Guide. This document is not intended as a replacement for the User's Guide and should only be used in conjunction with it. The User's Guide should be consulted for details regarding the precise steps to follow when performing the actual configuration. The discussion here is meant to provide you with an understanding of why the various configuration steps are necessary and how they ultimately fit together into a whole when their inter-relationships are fully comprehended. The first aspect of configuration in an IPCHAN environment that we'll discuss here is configuring the 3172. This is by far the most seemingly complex piece when compared with the configuration required at the mainframe (at least that required to achieve the most basic connectivity). As is made clear in the User's Guide, configuration at the 3172 involves four top-level steps: 1) Fill in copies of the worksheets from Appendix A with your network-specific configuration information. 2) Use IPYSETUP to let the 3172 know the details of the way in which the mainframes' channel links to the 3172 have been defined. 3) Use LAPS (OS/2 2.11) or MPTS (OS/2 3.0 Warp) to define the 3172's LAN adapters (both real and virtual) and the protocols (such as IP) that will use them. 4) Use TCPIPCFG (OS/2 2.11) or TCPCFG (OS/2 3.0 Warp) to tell the 3172's IP protocol layer which LAN interfaces (both real and virtual) it is to make use of in its IP router role, and their IP details. The first step is fairly self-explanatory. The point to emphasise here (and that will be emphasised again and again) is that, as far as the 3172's IP layer is concerned, all the channel connections to all the mainframes are just another LAN interface, one interface only. That is, the 3172's IP layer is entirely unaware that it is sending IP frames up channels to mainframes. As far as it is concerned, it is merely sending them onto another LAN; its view is identical to the logical view of the sample IPCHAN configuration illustrated in the principles section of this document. Thus, when filling in the LAPS/MPTS Adapters worksheet, the total number of LAN adapters you need to record information for is n + 1, where n is the number of real LAN adapters you wish to run TCP/IP over and the extra one is for the virtual LAN adapter that connects the 3172 to the IPCHAN Virtual LAN. The second step, above, is the one time when, from the 3172's perspective, you should think of the channel links as just that. In this step, you inform IPCHAN of the mainframes' channel configuration details: - Whether each connection is across an ESCON or Parallel channel (including ESCON- or PCA-specific details). - CLAW connection specifications of sub-channel addresses to use and "workstation" (i.e. 3172) and "host" (i.e. mainframe) CLAW-link names. - The mainframes' (own) home IP addresses (i.e. the IP addresses you've assigned to the mainframes at their ends of the channel connections). One detail that it is worth explicitly pointing out in this step is the last one, configuring the mainframes' IP addresses. The field in the IPYSETUP program is titled "Host IP Address" and refers to the IP address at the mainframe's end of the particular channel link you are defining at that time; that is, "host" in this context means "mainframe". What you're really doing in this second step is simply telling the 3172 how the mainframes it will be connected to have been configured so it knows how to communicate with them at the channel protocol level (IPCHAN uses CLAW). The third step is where you define which of the 3172's LAN adapters you wish to use with TCP/IP (not that this is the only use of this particular configuration tool but it is the one that is relevant to configuring IPCHAN). Remember that for this purpose, the channel links are to be considered as just another LAN adapter. The order suggested in the User's Guide for configuring LAN adapters is to start with the real ones. So if there are, say, three TR LAN Streamers in the 3172 and you wish to utilize them all for TCP/IP connectivity, then all three need to be defined in the Current Configuration sub-window. This involves choosing the correct MAC driver, from the Network Adapters sub-window, and then adding the IBM TCP/IP protocol driver, from the Protocols sub-window, to it, for all three real adapters. The same approach applies to configuring the IPCHAN virtual adapter: choose the correct MAC driver and add the TCP/IP protocol driver to it. The correct MAC driver for the IPCHAN Virtual LAN adapter is called "IP Access for Channel Adapter(s)". The TCP/IP protocol is added to it in the exact same manner as it was added to all the other MAC drivers. (Note that the number that appears to the left of the protocol(s) configured under each MAC driver is called the Logical Adapter Number for that specific LAN adapter; this information will prove useful in explanations to follow.) Once all the LAN adapters ('n' real and one virtual) have been configured in this step, they will be activated on the next re-boot of the 3172. The fourth, and final, step in configuring the 3172 for IPCHAN is setting-up the 3172's IP layer with the knowledge of which LAN interfaces it is to run IP over and telling it the interfaces' details that are needed for it to do so, such as IP addresses and subnet masks. Here again, the logical view of the IPCHAN environment serves us best when performing this task; i.e. the channel connections are represented by the IPCHAN Virtual LAN adapter. For each LAN adapter configured in the third step ('n' real and one virtual), you must tell the 3172's IP layer to use it by enabling the interface that corresponds to the LAN adapter's Logical Adapter Number (from step 3). So, once again assuming that you had configured a total of four LAN adapters (three real LAN Streamer adapters and one virtual IPCHAN adapter) in the order suggested, they would have Logical Adapter Numbers of 0, 1, 2 and 3. '0' would map to the LAN Streamer in the lowest physical slot, '1' would map to the LAN Streamer in the second lowest physical slot, '2' would map to the LAN Streamer in the third lowest physical slot, and '3' would map to the IPCHAN Virtual LAN adapter. Thus, we would wish to enable the IP interfaces with numbers 0, 1, 2 and 3. Having enabled them, we can then enter the necessary details into the appropriate fields based on our worksheet entries. It is worth taking special note again here, that when configuring the 3172's IP layer for its use of LAN interfaces, no special consideration need be given to the IPCHAN Virtual LAN interface (which is, in reality, a set of channel connections). As far as the 3172's IP layer is concerned, it is just another LAN interface. (This is certainly true, however the User's Guide suggests changing some of the default attributes of the IPCHAN Virtual LAN interface for TCP/IP's use: it recommends that Routing Field Support and ICMP Redirects be disabled. These subtle configuration changes are not essential for IPCHAN's proper operation but they do aid slightly in its efficiency.) Having finished the above four steps, configuration of IPCHAN in the 3172 is complete (the machine needs only to be re-booted). The next step is to configure the mainframes' TCP/IP protocols for IPCHAN connectivity. This involves entering various statements in each mainframe's PROFILE.TCPIP file, as detailed in the IPCHAN User's Guide and the various mainframe TCP/IP references. The basic statements covered in the User's Guide are fairly straightforward: DEVICE and LINK statement pairs to define each link to a 3172; HOME statements to define the IP addresses at the mainframes' ends of the channel connections; GATEWAY statements to define routes in a static routing environment (or BSDROUTINGPARMS statements to define links available to RouteD in a dynamic routing environment); and START statements for each device. Some issues regarding the use of IPCHAN in a dynamic routing environment have already been discussed in this document (specifically, with regards to RouteD, which implements RIP). As there has been some confusion regarding the definition of simple static routes in the GATEWAY statement (for use in a static routing environment), a few words with respect to this are in order. The example in the IPCHAN User's Guide is probably the simplest definition possible in a mainframe's GATEWAY statement: GATEWAY DEFAULTNET = BAMALNKA 2000 0 If all you wish to acheive is to have all TCP/IP traffic from a mainframe go down the channel to the 3172 (thus for it to be routed further by the 3172), then such a statement is all that is required. It simply defines one route, the default route, to the directly connected network accessible through the BAMALNKA channel link (with a 2000 byte packet size and no subnet mask). Once upon a time, the above statement worked for both MVS and VM TCP/IP mainframe systems. However, since MVS TCP/IP has been changed to provide VIPA support, this statement is no longer supported in the case of MVS TCP/IP. Were the VM TCP/IP developers to implement VIPA support then maybe it would no longer work on VM TCP/IP systems either, but it currently does (late 1996). All the other examples of GATEWAY statements in this document do currently work for both MVS and VM TCP/IP systems. Though the above statement will work as described, it may be easier to understand when expressed using the following two statements: GATEWAY 192.10.21 = BAMALNKA 2000 0 DEFAULTNET 192.10.21.1 BAMALNKA 2000 0 The default route explicitly states that the IP address of the router to send all the IP traffic to is 192.10.21.1 (the IP address of the 3172's connection to the IPCHAN Virtual LAN in the example we've been considering). The first statement is required so that the mainframe knows how to reach the 192.10.21 network so that it can send frames to the 192.10.21.1 router. The name and other details of the network link are exactly the same and the effect of these statements is identical to that of the first one, above. Again referring to the example used previously in this document, if we wanted to prevent IP traffic destined for the 192.10.22 network (the Ethernet) from being routed out of the mainframe, we could put some explicit routes in the GATEWAY section for the other networks only: GATEWAY 192.10.21 = BAMALNKA 2000 0 192.10.23 192.10.21.1 BAMALNKA 2000 0 The first routing statement tells the mainframe's IP layer that it is directly connected to the 192.10.21 network. Thus, anything destined for a machine on that network (i.e. any of the other mainframes or the 3172) can be sent down the BAMALNKA link. The second routing statement tells the mainframe that to reach the 192.10.23 network (the Token-Ring), it should send IP traffic to the 192.10.21.1 router (the 3172's connection to the IPCHAN Virtual LAN), also using the BAMALNKA channel link. Since there is no explicit route for the 192.10.22 network (the Ethernet) and there is no default route specified either, the mainframe doesn't know how to reach it; it can thus route no traffic to it. There are, of course, many more variations of static routing statements that one can configure in the GATEWAY section of mainframes' PROFILE.TCPIP files. The above is intended as a guide to the simpler configurations which seem to have been the main source of past confusion. Also, once the way in which the most basic of scenarios are configured is understood, the more complex scenarios should prove less diffcult. Those configuration aspects already discussed in this document are the core set around which most confusion has centered. As a result, no other areas will be considered here, for now. The most important concept to take away from this discussion is that of the IPCHAN Virtual LAN. It is a very powerful mental tool in assisting understanding of all aspects of the configuration process of the IPCHAN product.