IBM/Novell LAN Coexistence Introduction ------------ This section describes issues relating to the ability of IBM and Novell communications software to share LAN hardware, particularly as it relates to IBM's OS/2 LAN Requester v2.0 and the latest version of Novell's Requester for OS/2. "Coexistence" with NetWare means that IBM and Novell communications software share the same network hardware. An example is IBM and Novell communications software sharing a LAN adapter via different protocols (such as IEEE 802.2, NetBIOS, TCP/IP, IPX). and Database Manager) are involved. This document covers coexistence of the following IBM and Novell software: IBM software: OS/2 v2.0 OS/2 Extended Services v1.0 OS/2 LAN Server v2.0 OS/2 LAN Requester v2.0 Novell software: NetWare Requester for OS/2 v2.0 Previous versions of the OS/2 program made it difficult for two LAN .IFS files to be installed at one time, preventing the simultaneous operation, or coexistence, of OS/2 LAN Requester and Novell's NetWare Requester for OS/2. The enhanced functionality of the OS/2 program enables both IBM OS/2 LAN Requester and Novell NetWare Requester for OS/2 to be installed and configured to share the same LAN adapter and cabling. ODINSUP is Novell's new product to support the NDIS protocol stack on top of the ODI interface. Installing the ODINSUP driver requires modification of the CONFIG.SYS, NET.CFG, and PROTOCOL.INI files. This document explains how to modify these files. ODI Network Device Interface Specification (NDIS) Support --------------------------------------------------------- IBM OS/2 LAN Server v2.0 and ES v1.0 support NDIS-compatible network and protocol drivers. This support is an enhancement over LAN Server and Extended Edition v1.30.1, which provided NDIS-compatible communications only for Ethernet. Support of the NDIS architecture enables OS/2 LAN Requester to coexist with Novell NetWare Requester for OS/2 through Novell's Open Data-Link Interface (ODI) specification using the OS/2 v2.0 program. The ODI interface is similar to the NDIS interface in that it supports multiple LAN adapters and multiple protocols on a single workstation. The ODI interface creates a "logical network board", allowing multiple frame formats to be sent across the same network hardware. The main advantage of the ODI interface over NDIS is that protocol stack drivers (for example, for IPX, NetBIOS, TCP/IP) written to the ODI specification are not dependent on the type of LAN hardware topology being used. Therefore, programmers do not have to include code in their protocol device drivers to support specific LAN topologies. +---------+ +---------+----------+ | NETWARE | | LAN SVR | EXTENDED | |REQUESTER| |REQUESTER| SERVICES | +---------+ +---------+----------+ | IPX | | NETBIOS | 802.2 | +---------+ +---------+----------+ | | PROTOCOL MANAGER | | +--------NDIS--------+ | | ODINSUP | +----------------------------+--------------------+ | LSL - LINK SUPPORT LAYER | +-------------------------------------------------+ | ODI LAN DRIVER (I.E., TOKEN.SYS) | +-------------------------------------------------+ | ADAPTER | +-------------------------------------------------+ Changes to CONFIG.SYS --------------------- The Novell ODINSUP driver, ODINSUP.SYS, allows OS/2 LAN Requester v2.0 to coexist with other communications software compatible with IBM's NDIS communications configuration. When OS/2 LAN Requester v2.0 or Extended Services v1.0 is installed with NetBIOS support, a LAN-adapter-specific NDIS LAN driver is installed and loaded by the CONFIG.SYS. For example, if your network is an IBM Token-Ring network, the IBMTOK.OS2 NDIS MAC driver is installed. For communications coexistence to take place (as with OS/2 LAN Requester v2.0 and NetWare Requester for OS/2), the NDIS LAN driver is replaced with the ODI LAN driver for IBM Token Ring (TOKEN.SYS), and the Link Support Layer driver (LSL.SYS) must be added to support the building of the ODI stack. ODINSUP.SYS must be substituted into the NDIS stack to hook into the Link support layer (LSL). Example ------- Example 1 below is a portion of a CONFIG.SYS showing the configuration for OS/2 LAN coexistence using the OS/2 v2.0 programs, with an IBM Token-Ring as the primary adapter and a 3Com 3C523 Ethernet adapter as the secondary adapter. The order of loading is important. LSL.SYS and the ODI LAN driver(s) must be loaded before ODINSUP.SYS. The NDIS drivers PROTMAN.OS2 and NETBIND.EXE are still required and PROTMAN.OS2 must be loaded before ODINSUP.SYS. The protocol stack drivers (such as LANDD.OS2) must be be loaded before ODINSUP.SYS. Notice in the example that the NDIS MAC driver IBMTOK.OS2 is commented out. Its functionality has been replaced by the combination of LSL.SYS, TOKEN.SYS, and ODINSUP.SYS. NOTE: Except for the ODINSUP.SYS reference, all NetWare Requester references shown are added automatically be the NetWare Requester installation procedure. REM ----------BEGINNING OF CONFIG.SYS---------------------- . . . *Modify the LIBPATH to include the path to the .DLL files. This path *must be specified after the \MUGLIB\DLL directory entry to prevent *possible conflicts with the NETAPI.DLL in the C:\NETWARE directory. LIBPATH=C:\MUGLIB\DLL;...C:\NETWARE;... *Append to the PATH statement the path to the NetWare *OS/2 utilities (L:\OS2). SET PATH=C:\IBMLAN\NETPROG;...L:\OS2;... *Modify the DPATH to include the directory where the NetWare *message (.MSG) files were copied. SET DPATH=C:\IBMLAN\NETPROG;...;C:\NETWARE;... . . . REM --- NetWare Requester statements BEGIN --- *The Link Support Layer driver, LSL.SYS, begins the NetWare ODI *driver stack and must be loaded before any other NetWare driver. DEVICE=C:\NETWARE\LSL.SYS RUN=C:\NETWARE\DDAEMON.EXE *The ODI LAN driver must match the adapter installed. This example *is for IBM Token Ring. DEVICE=C:\NETWARE\TOKEN.SYS *Used only with TOKEN.SYS, ROUTE.SYS must load immediately after for *source routing. DEVICE=C:\NETWARE\ROUTE.SYS *This driver is for the 3Com 3C523 Ethernet (secondary adapter). DEVICE=C:\NETWARE\3C523.SYS *The IPX driver must be loaded after the ODI LAN driver. DEVICE=C:\NETWARE\IPX.SYS *The SPX driver is optional, but must be loaded to use the *printing utilities and Named Pipes. It is also required to run *Transport Level Interface (TLI) applications. DEVICE=C:\NETWARE\SPX.SYS RUN=C:\NETWARE\SPDAEMON.EXE *Named Pipe support is optional, and must be loaded after the SPX driver. *Two configurations are possible -- "client only" and "server". *Load the NMPIPE.SYS driver for Named Pipes client-only support. DEVICE=C:\NETWARE\NMPIPE.SYS *Load the NPSERVER.SYS driver, along with NMPIPE.SYS, for Named *Pipes server support. DEVICE=C:\NETWARE\NPSERVER.SYS *NPDAEMON.EXE must be executed for both Named Pipe configurations. *If configured as a "server", a server name must be specified. RUN=C:\NETWARE\NPDAEMON.EXE np_servername *The NetWare OS/2 requester driver must be loaded after IPX, SPX, *and the Named Pipes drivers. DEVICE=C:\NETWARE\NWREQ.SYS *The NetWare OS/2 Installable File System must be loaded after the *Requester driver. IFS=C:\NETWARE\NWIFS.IFS *The NetWare Daemon must be loaded after the NetWare OS/2 Requester *driver. RUN=C:\NETWARE\NWDAEMON.EXE *THE NETWARE NETBIOS DRIVER SHOULD NOT BE LOADED IN AN ES OR *LS environment. rem DEVICE=C:\NETWARE\NETBIOS.SYS rem RUN=C:\NETWARE\NBDAEMON.EXE *THE NETWARE SUPPORT FOR MVDMS IS OPTIONAL, BUT IT IS REQUIRED *TO RUN THE DOS NETWARE UTILITIES, IE SYSCON. DEVICE=C:\NETWARE\VIPX.SYS *The NetWare Print Spooler driver is optional. This is required *only if you want to print to a NetWare network printer queue. RUN=C:\NETWARE\NWSPOOL.EXE REM --- NetWare Requester statements END --- DEVICE=C:\IBMCOM\LANMSGDD.OS2 /I:C:\IBMCOM DEVICE=C:\IBMCOM\PROTMAN.OS2 /I:C:\IBMCOM DEVICE=C:\IBMCOM\PROTOCOL\LANDD.OS2 DEVICE=C:\IBMCOM\PROTOCOL\LANDLLDD.OS2 DEVICE=C:\IBMCOM\PROTOCOL\NETBEUI.OS2 *The ODINSUP.SYS driver must be loaded before NETWKSTA.SYS (.200). DEVICE=C:\NETWARE\ODINSUP.SYS *The NDIS MAC driver(s) must be commented out (IBMTOK.OS2 and *ELNKMC.OS2 in this example). rem DEVICE=C:\IBMCOM\MACS\IBMTOK.OS2 rem DEVICE=C:\IBMCOM\MACS\ELNKMC.OS2 RUN=C:\IBMCOM\PROTOCOL\LANDLL.EXE RUN=C:\IBMCOM\PROTOCOL\NETBIND.EXE RUN=C:\IBMCOM\LANMSGEX.EXE DEVICE=C:\IBMLAN\NETPROG\RDRHELP.200 IFS=C:\IBMLAN\NETPROG\NETWKSTA.200 /I:C:\IBMLAN *The NETBIOS.OS2 driver must be loaded after NETWKSTA.SYS (.200). DEVICE=C:\IBMCOM\PROTOCOL\NETBIOS.OS2 REM ---------END OF CONFIG.SYS--------------------------- Configuration using NET.CFG --------------------------- Several NetWare configuration concerns must be dealt with when installing the ODINSUP drivers. Most of these are resolved by modifying the NET.CFG file. This file is similar to the IBM OS/2 LAN Requester IBMLAN.INI file and the NDIS parameter file PROTOCOL.INI, which contain fields for configurable parameters. The NET.CFG file must be modified to update the following fields: o Increase the size of the Link support buffers. o Specify binding information for the ODINSUP protocol driver, ODINSUP.SYS (required if using multiple boards or if you don't want the default for a particular board). o Enable the supported frame types for the ODI LAN driver. When using ODINSUP.SYS, increase the size of the LSL buffers if you want packet sizes larger than the default of 1514. The default value is sufficient for Ethernet and for use with Token-ring cards supporting a maximum 2K frame size. For example, for Token-ring cards supporting 4K frame sizes (newer 16/4 cards) a packet size of 4210 is recommended. For older cards with maximum frame size of 2K, add this statement: link support buffers 15 1514 For newer cards with maximum frame size of 4K, add this statement: link support buffers 15 4210 When the NetWare Requester is initialized, it tries to establish a connection with the primary network board. Use of multiple network boards can increase communication speed if the workstation is connected to multiple physical networks. The ODINSUP driver must bind to an ODI LAN driver for network communication to take place. If no binding information is specified in the NET.CFG file, ODINSUP, by default, attempts to locate a supported ODI LAN driver. If an ODI LAN driver is found, ODINSUP.SYS attempts to bind to it. To support more than one ODI LAN driver or to specify which ODI LAN driver to bind to requires modification to the NET.CFG file. ODINSUP.SYS can be bound to as many as four ODI LAN drivers. A bind entry specifies the name of the ODI LAN driver and, optionally, the instance number of the adapter. The name of the ODI LAN Driver is usually the name of the ODI LAN driver file (such as, TOKEN for TOKEN.SYS, etc.). If more than one LAN adapter is installed in the workstation (such as, two 3C523 adapters), the instance number may be required. If an instance number is not specified, ODINSUP.SYS will bind to the first ODI LAN driver found. For example, if two 3C523 (3Com Ethernet) adapters were installed, ODINSUP.SYS would bind to the first loaded instance of the ODI LAN driver. If not specified, the default value for the instance number is 1. Example NET.CFG: link support buffers 15 4210 protocol odinsup bind token ;Bind to the first instance of TOKEN ODI LAN driver bind 3c523 1 ;Bind to the first instance of 3C523 ODI LAN driver bind 3c523 2 ;Bind to the second instance of 3C523 ODI LAN driver Currently, ODINSUP.SYS supports only ODI LAN drivers compatible with Token-Ring and Ethernet LANs. The NET.CFG file must by modified to enable the minimum number of frame types for Token-Ring and Ethernet. For token-ring ODI LAN drivers, the TOKEN-RING, and TOKEN-RING_SNAP frame types must be specified. For the Ethernet ODI LAN driver, the ETHERNET_802.2, ETHERNET_SNAP, and ETHERNET_II frame types must be specified. The following is a sample NET.CFG file showing how these frame types are specified. Example NET.CFG: link support buffers 15 4210 protocol odinsup bind token ;Bind to the first instance of TOKEN ODI LAN driver bind 3c523 1 ;Bind to the first instance of 3C523 ODI LAN driver bind 3c523 2 ;Bind to the second instance of 3C523 ODI LAN driver link driver token frame token-ring ;Required frame token-ring_snap ;Required link driver 3c523 frame ethernet_802.3 ;Optional frame ethernet_802.2 ;Required frame ethernet_ii ;Required frame ethernet_snap ;Required The NET.CFG file can be used for other NetWare Requester configuration requirements. Refer to the Novell booklet, "NetWare Requester for OS/2" that that comes with the NetWare Operating System documentation for more information on how to configure the NetWare drivers using the NET.CFG file. file. Changes to PROTOCOL.INI ----------------------- The NDIS PROTOCOL.INI file is required to tell the NDIS protocol(s) which ODINSUP driver to bind to. Usually, all PROTOCOL.INI information for NDIS MAC drivers can be removed, because no ODI MAC-specific information is necessary in the PROTOCOL.INI. The PROTOCOL.INI must also specify sections for each NDIS protocol used. For example, one section is the "Bindings = ..." statement, which specifies the NDIS MAC(s) that the protocol should bind to. The name specified should be the name of the ODI LAN Driver installed (such as 3C523, TOKEN, or 3C503). If the ODI LAN Driver name starts with a number (such as 3C523), the MAC name for the "Bindings = ..." statement must be preceded with the letter 'x'. Therefore, the "Bindings = ..." statement for the 3C523 LAN driver would be "Bindings = x3C523". If binding to multiple ODI LAN drivers, the entries on the "Bindings = ..." statement should be separated by a comma (such as Bindings = TOKEN,X3C503 ). When an adapter instance other than the first is used (such as when ODINSUP.SYS is bound to the second TOKEN ODI LAN Driver), the MAC name must have the instance number appended to the end of the ODI LAN driver name (such as TOKEN2 for the second instance, x3C5234 for the fourth instance). Appropriate MAC names are displayed when ODINSUP.SYS is loaded. The following example is PROTOCOL.INI file for OS/2 v1.30.2 and OS/2 v2.0 running OS/2 LAN Requester v2.0 and NetWare Requester for OS/2. This example shows the binding instruction changes required for the ODINSUP driver: {PROT_MAN} DriverName = PROTMAN$ {IBMLXCFG} LANDD_nif = LANDD.nif NETBEUI_nif = NETBEUI.nif ;*----------------------------------------------* ;*------------- PROTOCOL SECTION ---------------* ;*----------------------------------------------* {LANDD_nif} DriverName = LANDD$ ; Bindings = IBMTOK_nif,ELNKMC_nif ; For first instance of TOKEN board and first instance of 3C523 board. Bindings = TOKEN,x3C523 {NETBEUI_nif} DriverName = netbeui$ ; Bindings = IBMTOK_nif,ELNKMC_nif ; For first instance of TOKEN board and first instance of 3C523 board. Bindings = TOKEN,x3C523 ;*--------END OF FILE---------------------------* NOTE: The above PROTOCOL.INI example is a complete file. All portions of the PROTOCOL.INI that are NDIS-related may be deleted or remarked out. The following example is PROTOCOL.INI file for OS/2 EE v1.30.1, using the NDIS-compatible Ethernet MAC driver for the 3Com 3C523 adapter: ;------------------ Protocol Manager Definition ----------------- {PROTOCOL_MANAGER} DriverName = PROTMAN$ ;---------------- IBM ETHERAND Protocol Definition -------------- {ETHERAND} DriverName = OS2EE$ Bindings = x3C523 ;for first instance of 3C523 board ; Bindings = x3C5232 ;for second instance of 3C523 board ;---------END OF FILE----------------- NOTE: Communications Manager cannot handle an OS2EE entry such as "Bindings = x3C523,x3C5232". Limitations ----------- The ODINSUP.SYS driver for OS/2 requires LSL.SYS that is dated later than May 19, 1991. Also, TOKEN.SYS dated earlier than Sept. 17, 1991 does not support ODINSUP.SYS. The ODINSUP driver is supported only for those configurations for which an ODI-compatible LAN driver for the network adapter(s) is available. This requirement may limit the use of ODINSUP (especially in the Ethernet environment) because Novell ships a limited number of ODI LAN drivers with its latest release of the NetWare Requester for OS/2. At this time, several ODI LAN adapter drivers are being developed by third-party vendors, but no release data is available. Currently, starting the IBM OS/2 LAN Server on a machine with the NetWare Requester drivers installed is not officially supported. However, most environments where this configuration is attempted should execute successfully. Trademarks ---------- 3Com is a trademark of 3Com Corporation. IBM is a registered trademark of International Business Machines Corporation. NetWare and Novell are registered trademarks of Novell, Inc. OS/2 is a trademark of International Business Machines Corporation. Token-Ring is a trademark of International Business Machines Corporation. ------------------------------------------------------------------------ ------------------------------------------------------------------------ ------------------------------------------------------------------------