******************************************************************************************************************************* NOTE: The origin of this information may be internal or external to Novell. Novell makes every effort within its means to verify this information. However, the information provided in this document is FOR YOUR INFORMATION only. Novell makes no explicit or implied claims to the validity of this information. ******************************************************************************************************************************* NETWARE TCP/IP INSTALLATION AND CONFIGURATION ON A NETWARE 3.11 FILESERVER OCTOBER 1992 (This document DOES NOT include configuration of IP Tunnelling and Network Management using SNMP. IP Tunnelling is covered in Appendix A and SNMP is covered in Chapter 6 of the NetWare TCP/IP Transport Supervisor's Guide.) ORGANIZATION OF THIS DOCUMENT ----------------------------- I. PREREQUISITES FOR RUNNING TCP/IP II. LOADING AND CONFIGURING NETWARE TCP/IP (as a TCP/IP node and a TCP/IP router) III. POINTS TO CONSIDER WHEN CONFIGURING TCP/IP AS A NETWARE IP ROUTER 3.1 IP ROUTING BETWEEN DIFFERENT NETWORK SEGMENTS WITH THE NW311 ROUTER 3.2 SUBNETTING 3.3 SUBNET ZERO 3.4 CONFIGURING NETWARE TCP/IP WITH SUBNETS EXAMPLE 1A EXAMPLE 1B EXAMPLE 1C EXAMPLE 2 3.5 CLASS B AND C SUBNETS IV. TESTING THE CONFIGURATION STEP ONE STEP TWO STEP THREE APPENDIX A - TOKEN RING SOURCE ROUTING A.1 SOURCE ROUTING CONFIGURATION ON THE NETWARE FILESERVER A.2 SOURCE ROUTING CONFIGURATION ON A WORKSTATION APPENDIX B - INFORMATION TO PROVIDE WHEN PLACING A TECHNICAL SUPPORT CALL I. PREREQUISITES ----------------- * Computer - 80386- or 80486-based PC running NetWare 3.11 or higher * RAM - At least 4MB * LAN Adapter - Ethernet, Token-Ring or ARCNET adapter and corresponding driver * LAN Driver - must be certified for NetWare 3.11 ( Refer to page 2-1 of the "NetWare TCP/IP Transport Supervisor's Guide" for more information.) II. LOADING AND CONFIGURING NETWARE TCP/IP ------------------------------------------- NetWare TCP/IP comes standard with the NetWare 3.11 OS. NetWare TCP/IP does not provide TCP/IP applications such as Telnet, FTP, etc.. These services are provided by TCP/IP solutions such as Novell's LAN WorkPlace for DOS (LWPD). NetWare TCP/IP provides the IP router and IP Tunnelling functions and SNMP management on the NetWare 3.11 fileserver, which allows IP packets to be forwarded through the fileserver to remote networks. The installation of TCP/IP is accomplished when the NetWare OS is installed. If this is a first time install, you may wish to test each command by entering each individually at the NetWare console prompt before placing them in the AUTOEXEC.NCF file . 1. Enter the following setting in the STARTUP.NCF file: SET MAXIMUM PHYSICAL RECEIVE PACKET SIZE = 1514 This is discussed on page 259 of the "NetWare 3.11 System Administration Guide". For Ethernet or ARCNET networks the setting should be 1514. For Token-Ring networks the setting should be set to 4202. (NOTE: If the fileserver is connecting an Ethernet or ARCNET network to a Token-Ring network, the value in the STARTUP.NCF file on the fileserver should be the greatest packet size which would be 4202.) Enter the following setting in the AUTOEXEC.NCF file: SET MAXIMUM PACKET RECEIVE BUFFERS = 200 This is discussed on page 2-3 of the "NetWare TCP/IP Transport Supervisor's Guide" and page 260 of the "NetWare 3.11 System Administration Guide". Depending on the TCP/IP applications and their usage, you may need to increase the value of the Maximum Packet Receive Buffers parameter. The default value is 100 buffers, which may be insufficient for some configurations (supported values are 50 through 2000). You can use MONITOR.NLM to observe the number of Packet Receive Buffers currently allocated, to determine whether the current limit is sufficient. If many TCP/IP applications are concurrently active, then the buffering needs are greater. (See page 260 of the "NetWare 3.11 System Administration Guide" for more information on determining what value to set for this parameter.) To get on-line help with the SET commands, at the NetWare console prompt enter "SET", then select option "1" for Communications, then "ADVANCED", and then the specific SET option you want information on. 2. The LOAD TCPIP command usually located in the AUTOEXEC.NCF file, determines whether NetWare TCP/IP on the 3.11 fileserver will be recognized as a TCP/IP host on the network or as an IP router between two or more networks (either Ethernet, Token-Ring, or ARCNET). To be seen as a TCP/IP host on the network, enter the command: LOAD TCPIP If the NetWare 3.11 fileserver is to route IP packets, the command would be: LOAD TCPIP FORWARD=YES Three options that can be specified with the LOAD TCPIP command: LOAD TCPIP [FORWARD = {YES|NO}] [RIP = {YES|NO}] [TRAP = ip_address] "FORWARD = YES" configures the server as an IP router; default is NO. RIP enables or disables routing information protocol; default is YES. TRAP specifies the IP address to which the local system should send SNMP trap messages. For more information, see pages 3-2 through 3-4 in the "NetWare v3.11 TCP/IP Transport Supervisor's Guide". 3. Load the LAN driver. For an Ethernet LAN driver: LOAD lan-driver INT=int PORT=port FRAME=ETHERNET_II NAME=ip_enet For a Token-Ring LAN driver: LOAD lan-driver FRAME=TOKEN-RING_SNAP NAME=ip_token For an ARCNET LAN driver: LOAD lan-driver INT=int PORT=port FRAME=NOVELL_RX-NET NAME=ip_arc NOTE: The "NAME" given at the end of each line is a unique name that you select when loading the LAN driver re-entrantly with more than one frame type. For example, if loading IPX and IP to the same LAN controller, the IPX LOAD statement might have NAME=IPX_LAN and the IP LOAD statement might have NAME=IP_LAN. LOAD NE3200 INT=3 PORT=300 FRAME=ETHERNET_802.3 NAME=IPX_LAN LOAD NE3200 INT=3 PORT=300 FRAME=ETHERNET_II NAME=IP_LAN For more information refer to Chapter 3 of the "NetWare TCP/IP Transport Supervisor's Guide" or to pages 122 through 154 in the "NetWare 3.11 System Administration" manual. 4. Follow the above command with BIND command: BIND IPX TO name NET=# BIND IP TO name ADDR=#.#.#.# [MASK= subnet mask] "NET" is the IPX network number. "name" is the value assigned in the LOAD statement as the "NAME" parameter. "ADDR" is the IP address to be assigned to this NIC. "MASK" (optional) is used if a subnet is specified on the network. "#" specifies a numerical value which can be in either decimal or hexidecimal, eg. 255.255.255.255.0 or FF.FF.FF.0. The BIND command has several options which are explained in the "NetWare TCP/IP Transport Supervisor's Guide" on page 3-4 through 3-8. For more information about IP addressing, please refer to Appendix B of the "NetWare TCP/IP Transport Supervisor's Guide". An example of the BIND commands: BIND IPX to IPX_LAN NET=2 BIND IP to IP_LAN ADDR=130.2.1.254 MASK=FF.FF.FF.0 An example of entries in the NetWare 3.11 AUTOEXEC.NCF file to provide routing of IP and IPX packets between Ethernet, Token Ring, and ARCNET networks: SET MAXIMUM PACKET RECEIVE BUFFERS = 200 LOAD TCPIP FORWARD=YES LOAD NE3200 int=3 port=300 frame=ETHERNET_802.3 name=IPX_LAN LOAD NE3200 int=3 port=300 frame=ETHERNET_II name=IP_LAN LOAD TOKEN frame=ETHERNET_802.3 name=IPX_TOKEN LOAD TOKEN frame=TOKEN-RING_SNAP name=IP_TOKEN LOAD SMCPLUSSV int=5 port=320 frame=NOVELL_RX-NET NAME=ARCNET BIND IPX to IPX_LAN net=1 BIND IP to IP_LAN addr=130.2.1.254 mask=FF.FF.FF.0 BIND IPX to IPX_TOKEN net=2 BIND IP to IP_TOKEN addr=130.2.2.254 mask=FF.FF.FF.0 BIND IPX to ARCNET net=3 BIND IP to ARCNET addr=130.2.3.254 mask=255.255.255.0 For additional sample IP network configurations, refer to Chapter 5 of the "NetWare TCP/IP Transport Supervisor's Guide". In the above example note that there is only one LOAD statement for ARCNET. For any topology (Ethernet, Token Ring, or ARCNET) when the same frametype is used for both IPX and IP, only one LOAD statement is required. ARCNET uses the same frametype (NOVELL_RX-NET) for IPX and IP. NOTE: If all of the servers on the network are NetWare 3.11, Ethernet NICs may have both IPX and IP bound to the LAN driver with ETHERNET_II for easier configuration (one LOAD statement with the frametype ETHERNET_II and two BIND statements with one for IP and the other for IPX). If other NetWare servers on this network have the frametype Ethernet_802.3, then you will need to load both frametypes (Ethernet_802.3 for IPX and Ethernet_II for IP) as described in the configuration above. III. POINTS TO CONSIDER WHEN CONFIGURING TCP/IP AS A NETWARE IP ROUTER ----------------------------------------------------------------------- IP addresses are differentiated into three classes based on the two most significant bits of the first of four bytes. This is done so that routers can efficiently extract the network portion of the address. A good reference for further study is "Internetworking with TCP/IP" by Douglas E. Comer. An IP address consists of two parts, the network address and the host address. "n"=network address, "h"=host address Class A 0nnnnnnn.hhhhhhhh.hhhhhhhh.hhhhhhhh 7 bits of network address, 24 bits of host address Class B 10nnnnnn.nnnnnnnn.hhhhhhhh.hhhhhhhh 14 bits of network address, 16 bits of host address Class C 110nnnnn.nnnnnnnn.nnnnnnnn.hhhhhhhh 21 bits of network address, 8 bits of host address Where the first byte of an IP address fits in ranges listed below, tells you to which of the three network classes the address belongs. The three IP network classes are: Class A 1 to 127 (Class A: 1.h.h.h - 127.h.h.h). Class B 128 to 191 (Class B: 128.n.h.h - 191.n.h.h). Class C 192 to 223 (Class C: 192.n.n.h - 223.n.n.h). An IP address beginning with 154 would be a Class B address, with the first two bytes of the address representing the "n"etwork portion of the address and the last two representing the "h"ost portion. For example, an IP address of 154.1.0.3 means the IP network portion would be 154.1.0.0 and the host portion on that network would be #.#.0.3. (Refer to pages B-7 through B-9 of the "NetWare TCP/IP Transport Supervisor's Guide" for more information on IP addressing.) The network portion of an IP address should be the same for all nodes that belong to the same network. The NIC in the fileserver that is connecting to network 89.0.0.0 needs to have a unique IP host address assigned to it, such as 89.0.0.254. (NOTE: The key to selecting a number for the host portion of the IP address is to make sure that the number selected is unique, that no other host on the network has the same IP address.) 3.1 IP ROUTING BETWEEN DIFFERENT NETWORK SEGMENTS WITH THE NW311 ROUTER ------------------------------------------------------------------------ Routing packets is done between different physical networks. When the NetWare server is used as an IP router between two or more networks, each network has to have a unique IP "network" address. The IP addresses of the different network interface cards (NICs) in the NetWare 3.11 fileserver should have different IP network addresses corresponding to the networks they are connected to. (This is defined in the BIND IP statement in the AUTOEXEC.NCF file.) Each board in the NetWare 3.11 fileserver needs to have a different IP network address so that the fileserver can route IP packets to the appropriate network. IP routing occurs between different networks; if one board in the fileserver is connected to network 89.0.0.0, then the second board in the fileserver needs to be connected to a different network such as 192.1.1.0. The board connected to IP network 89.0.0.0 needs an IP address of 89.#.#.# in order to be recognized on this network. The second board in the fileserver that is connected to network 192.1.1.0 will need an address of 192.1.1.#. 3.2 SUBNETTING --------------- In the "NetWare TCP/IP Transport Supervisor's Guide" on pages B-18 and B-19 the reasons given for subdividing your network are: . to use multiple media . to reduce congestion . to reduce CPU use . to isolate a network . to improve security. If an organization has been assigned a single IP network address, then hey must use subnets to accomplish any of these goals. That is, they can partition the host address space by assigning subnet numbers to the LANs. (If a unique network number can be acquired for each LAN, then subnets may not be necessary.) For more information regarding methods of partitioning your network refer to page B-19 of the "NetWare TCP/IP Transport Supervisor's Guide". With subnetting, IP addresses may be interpreted as: The part is defined by the IP network address and the and parts are defined by the subnet mask. For example, a company has been assigned the Class B IP network number of 154.4.0.0, and wants to implement subnet masking. This can be done by using a mask that maps off all or part of the third byte. With a mask of 255.255.255.0 (FF.FF.FF.0), the first three bytes of the IP address would now be recognized as the network portion of the address. Now the network portion of the address would be 154.4.1.0 instead of 154.4.0.0. With this mask, there is a total of 254 subnets that could be assigned, from 154.4.1.0 to 154.4.254.0. The following diagram gives the binary and decimal representation of the 3rd byte with a subnet mask of 255.255.255.0 (FF.FF.FF.0): BINARY VALUE (subnet mask) - | 1 1 1 1 | | 1 1 1 1 | BINARY VALUE (subnet mask) - | n n n n | | n n n n | (n = network, h = host portion) DECIMAL VALUE (for each bit) - | 128 64 32 16 | | 8 4 2 1 | ---------------------------- For more information on creating a subnet and the characteristics of a subnet refer to pages B-20 through B- 22 in the "NetWare TCP/IP Transport Supervisor's Guide". 3.3 SUBNET ZERO ---------------- A subnet of all zeros is not recommended by RFC 950 and is not supported by Novell. The subnet field must not contain all zeros; this is not supported and should not be used for subnet masking with NetWare TCP/IP. For example, using the Class B network address of 154.4.0.0 with a mask of 255.255.255.0 (FF.FF.FF.0), and then assigning "0" as the value for the third byte still appears as the original address, as if the subnet mask was NOT being implemented (i.e., 154.4.0.0). 3.4 CONFIGURING NETWARE TCP/IP WITH SUBNETS -------------------------------------------- If no subnet mask is assigned, the subnet mask is the default IP network mask assigned to each class of IP network. For example: Class A IP addressing is 1 to 127 and has a default subnet mask of 255.0.0.0 (FF.0.0.0) Class B IP addressing is 128 to 191 and has a default subnet mask of 255.255.0.0 (FF.FF.0.0) Class C IP addressing is 192 to 223 and has a default subnet mask of 255.255.255.0 (FF.FF.FF.0) If it is determined that subnet masking needs to be configured on the network, all hosts on that network need to be configured with that mask. On the NetWare TCP/IP fileserver, the mask is configured with the BIND command: BIND IP TO lan-driver ADDR=#.#.#.# MASK= #.#.#.# (NOTE: The subnet mask can be assigned using either hexadecimal values of 0 through F, or decimal values of 0 through 255. For example, the values of "FF.FF.0.0" and "255.255.0.0" are the same, and either can be loaded in the AUTOEXEC.NCF file.) In assigning the subnet mask, make the subnet bits contiguous and located as the most significant bits of the IP address. (Even though it is not illegal to have noncontiguous bits, it is recommended that bits in the subnet mask be contiguous in order to avoid more confusion with subnet masking and IP addressing.) For example, the binary representation of a subnet mask of 255.255.49.0 (FF.FF.31.0) is: |1111 1111| |1111 1111| |0011 0001| |0000 0000| By having the bits of the subnet mask non-contiguous and not located as the most significant bits of the IP address, it becomes more difficult to determine which portion of the IP address is the subnet (network) portion and which bits represent the unique host address. A more desirable approach is to use a subnet mask of 255.255.224.0 (FF.FF.E0.0), with the binary representation: |1111 1111| |1111 1111| |1110 0000| |0000 0000| The simpest method of subnet masking is to mask off an entire byte, as described in an earlier example. However, you can mask off only a portion of a byte as the network address. To do this you need to recognize which bits in the byte represent the network and the host portions, then calculate the appropriate subnet mask. EXAMPLE 1 --------- For this example we are using the Class C IP address of 192.1.1.0 which has a default mask of 255.255.255.0 (FF.FF.FF.0). To allow subnetting, mask off the first two bits of the 4th byte with the IP subnet mask of 255.255.255.192 (FF.FF.FF.C0). This allows you the following network combinations: 192.1.1.0 (neither the 8th or 7th bits are turned on) ... subnet zero 192.1.1.64 (7th bit of 4th byte turned on) 192.1.1.128 (8th bit of 4th byte turned on) 92.1.1.192 (8th and 7th bits of 4th byte turned on)... subnet all ones Therefore a subnet mask of 255.255.255.192 (FF.FF.FF.C0) would provide two valid subnet networks of 192.1.1.128 and 192.1.1.64. (You can not have subnet zero (192.1.1.0) or all ones (192.1.1.192).) Using this subnet mask with the single IP network address would provide two functional IP networks. ******************************************************************************************************************************* NOTE: It is recommended by RFC 950 that the values of all zeros, and all ones in the subnet field should not be assigned in the subnet portion of the IP address. ******************************************************************************************************************************* EXAMPLE 1-A ----------- The fourth byte of the IP address on the network 192.1.1.128, with the subnet mask of 255.255.255.192, can be a decimal value between 129 and 191 inclusive (providing available host addresses between 192.1.1.129 and 192.1.1.191 inclusive). The fourth byte is made up of both the subnet network number and the host portion of the IP address. In this example, the value of the fourth byte is made up of the combination of the subnet network number (#.#.#.128) plus any combination of the last six bits (32, 16, 8, 4, 2, 1) that are the host address portion of the fourth byte. For example, a value of #.#.#.139 breaks down to 128 as the subnet network number, leaving a host number of 11 (139 - 128 = 11). The following diagram gives the binary and decimal representation of the fourth byte with a subnet mask of 255.255.255.192 (FF.FF.FF.C0): BINARY VALUE (subnet mask) - | 1 1 0 0 | | 0 0 0 0 | BINARY VALUE (subnet mask) - | n n h h | | h h h h | (n = network, h = host portion) BINARY VALUE (network #.#.#.128) | 1 0 0 0 | | 0 0 0 0 | BINARY VALUE (IP addr #.#.#.139)| 1 0 0 0 | | 1 0 1 1 | DECIMAL VALUE (for each bit) - | 128 64 32 16 | | 8 4 2 1 | NOTE: The value of "64" can not be used in determining the IP address of the fourth byte. Because of the subnet mask 255.255.255.192 (FF.FF.FF.C0), the 7th and 8th bits of the fourth byte with the values of 64 and 128 respectively are recognized as the network portion of the address. Since this example is using 192.1.1.128 as the network address, the value of "64" can not be used. It is seen as addressing for another network. EXAMPLE 1-B ----------- The fourth byte of the IP address on the network 192.1.1.64, with the subnet mask of 255.255.255.192, can be assigned a decimal value between 65 and 127 inclusive (providing available host addresses between 191.1.1.65 and 191.1.1.127 inclusive). The fourth byte is made up of both the subnet network number and the host portion of the IP address. In this example, the value of the fourth byte is made up of the combination of the subnet network number (#.#.#.64) plus any combination of the last six bits (32, 16, 8, 4, 2, 1) that are the host address portion of the fourth byte. For example, a value of #.#.#.116 breaks down to 64 as the subnet network number and a host number of 52 (116 - 64 = 52). The following diagram gives the binary and decimal representation of the fourth byte with a subnet mask of 255.255.255.192 (FF.FF.FF.C0): BINARY VALUE (subnet mask) - | 1 1 0 0 | | 0 0 0 0 | BINARY VALUE (subnet mask) - | n n h h | | h h h h | (n = network, h = host portion) BINARY VALUE (network #.#.#.64) | 0 1 0 0 | | 0 0 0 0 | BINARY VALUE (IP addr #.#.#.116)| 0 1 1 1 | | 0 1 0 0 | DECIMAL VALUE (for each bit) - | 128 64 32 16 | | 8 4 2 1 | NOTE: The value of "128" can not be used in determining the IP address of the fourth byte. Because of the subnet mask 255.255.255.192 (FF.FF.FF.C0), the 7th and 8th bits of the fourth byte with the values of 64 and 128 respectively are recognized as the network portion of the address. Since this example is using 192.1.1.64 as the network address, the value of "128" can not also be used. It is seen as addressing for another network. EXAMPLE 1-C ----------- The BIND statements for two cards in a NetWare fileserver could be: BIND IP to IPNET1 ADDR=192.1.1.139 MASK=255.255.255.192 BIND IP to IPNET2 ADDR=192.1.1.116 MASK=255.255.255.192 NOTE: The IP network addresses of 192.1.1.128 and 192.1.1.64 (with the subnet mask of 255.255.255.192), are network addresses and should not be assigned to TCP/IP hosts. These are network addresses and not to be used as host addresses. For example, the following BIND commands would be ILLEGAL: BIND IP to IPNET1 ADDR=192.1.1.128 MASK=255.255.255.192 (ILLEGAL ADDRESS) BIND IP to IPNET2 ADDR=192.1.1.64 MASK=255.255.255.192 (ILLEGAL ADDRESS) EXAMPLE 2 --------- For this example we are using the Class C IP address of 192.1.1.0 which has a default mask of 255.255.255.0 (FF.FF.FF.0). To allow subnetting, we are going to mask off the first three bits of the last byte with the IP subnet mask of 255.255.255.224 (FF.FF.FF.E0). This would give you the following network combinations: 192.1.1.0 (neither the 6th,7th or 8th bits are turned on) .... subnet zero 192.1.1.32 (6th bit, of 4th byte turned on) 192.1.1.64 (7th bit, of 4th byte turned on) 192.1.1.128 (8th bit, of 4th byte turned on) 192.1.1.96 (6th and 7th bits, of 4th byte turned on) 192.1.1.160 (6th and 8th bits, of 4th byte turned on) 192.1.1.192 (7th and 8th bits, of 4th byte turned on) 192.1.1.224 (6th, 7th and 8th bits, of 4th byte turned on)... subnet all ones When masking off the first three bits in the last byte (with the subnet mask of 255.255.255.224 (FF.FF.FF.E0)), the recommended six network addresses would be: 192.1.1.32 192.1.1.64 192.1.1.96 192.1.1.128 192.1.1.160 192.1.1.192 The following diagram gives the binary and decimal representation of the 4th byte with a subnet mask of 255.255.255.192 (FF.FF.FF.E0): BINARY VALUE (subnet mask) - | 1 1 1 0 | | 0 0 0 0 | BINARY VALUE (subnet mask) - | n n n h | | h h h h | (n = network, h = host portion) DECIMAL VALUE (for each bit) - | 128 64 32 16 | | 8 4 2 1 | 3.5 CLASS B and C SUBNETS -------------------------- Possible Class C subnets: BITS SUBNET MASK # of SUBNETS # of HOSTS (recommended) 2 255.255.255.192 2 62 3 255.255.255.224 6 30 4 255.255.255.240 14 14 5 255.255.255.248 30 6 6 255.255.255.252 62 2 Possible Class B subnets: 2 255.255.192.0 2 16382 3 255.255.224.0 6 8190 4 255.255.240.0 14 4094 5 255.255.248.0 30 2046 6 255.255.252.0 62 1022 7 255.255.254.0 126 510 8 255.255.255.0 254 254 9 255.255.255.128 510 126 10 255.255.255.192 1022 62 11 255.255.255.224 2046 30 12 255.255.255.240 4094 14 13 255.255.255.248 8190 6 14 255.255.255.252 16382 2 For more information on subnet masking, read pages B-18 through B-22 in the "Novell TCP/IP Transport Supervisor's Guide" and RFC 950. IV. TESTING THE NETWARE TCP/IP CONFIGURATION --------------------------------------------- For purposes of illustration, assume that the network configuration we are going to test consists of a DOS workstation running LAN WorkPlace for DOS (LWPD) on a physical network, which is attempting to connect to a UNIX host on another network, with a NetWare 3.11 fileserver routing IP packets between the two networks. LWPD - 191.1.1.45 subnet mask 255.255.255.224 (IP network 191.1.1.32) NW3.11 (board 1) - 191.1.1.60 subnet mask 255.255.255.224(IP network 191.1.1.32) NW3.11 (board 2) - 191.1.1.140 subnet mask 255.255.255.192 (IP network 191.1.1.128) UNIX - 191.1.1.137 subnet mask 255.255.255.192 (IP network 191.1.1.128) LWPD NW3.11 fileserver UNIX host ---------------------- ---------------------- ---------------------- | | | <- 191.1.1.60 | | | | 191.1.1.45 -> |---| (255.255.255.224) | | <- 191.1.1.137 | | (255.255.255.224) | | |---| (255.255.255.192) | ---------------------- | 191.1.1.140 -> | ---------------------- | (255.255.255.192) | ---------------------- Once the IP addressing has been configured, you are ready to test the configuration to see if IP packets can be routed between the two networks. The easiest way to do this is with the PING command. Testing can be initiated from either the LWPD workstation or from the UNIX system. In this example we will do testing from the LWPD workstation. STEP ONE -------- To test the IP connection between the workstation and the fileserver, enter the following command from the LWPD workstation: ping 191.1.1.60 If the response that is returned is "191.1.1.60 is alive", the IP packet was successfully sent to the remote address and the remote host (the fileserver) was able to return the packet successfully. If you do not receive the confirmation that the IP packet was returned correctly, there is a problem. At this point, the board on the NetWare fileserver should appear as another host on the local network so there should not be any routing issues. Things to check include: (1) that the network portion of the IP addresses on both the workstation and the fileserver are the same. (2) the workstation and the fileserver use the same subnet mask (which could be the default mask). (3) the physical connection between the two hosts exists and is good. STEP TWO -------------- The next step in the testing process is to ping from the LWPD workstation, through the fileserver, to the second board that is connected to the remote network: ping 191.1.1.140 If the test is not successful: (1) Verify that AUTOEXEC.NCF on the server contains the command "LOAD TCPIP FORWARD=YES" in order to route IP packets through the fileserver. (2) Verify that the LWPD workstation has the entries "IP_ROUTER 191.1.1.60" and "IP_NETMASK 255.255.255.224" in the NET.CFG file, to indicate that the host at 191.1.1.60 (the NetWare fileserver) is the router to route packets from network 191.1.1.32 to network 191.1.1.128. (For an example of the TCP/IP entries that need to be in the NET.CFG file, refer to page 2-10 of the "LAN WorkPlace for DOS Administrator's Guide".) (3) Verify the TCP/IP configuration on the fileserver by entering "CONFIG" at the console prompt and verify that the IP address and the subnet mask are being recognized as the values you configured in the AUTOEXEC.NCF file. (4) If you are not able to resolve the problem you may want to contact your local Novell Reseller, or post a message on NetWire, or call Novell TCP/IP Technical Support at 800-NETWARE (801-429-5588 for international calls) . Your Novell Reseller may want to work with Novell directly since your reseller may not incur a fee. (Before calling your Novell Reseller, or posting a message on NetWire, or calling Novell, please have the information available that is outlined in Appendix B.) Once you are successfully able to ping the second board in the fileserver, the routing on the LWPD workstation (the local TCP/IP host) is set up correctly and the NetWare fileserver is routing packets correctly. STEP THREE ---------- The final step in testing the configuration, is to ping from the LWPD workstation to the UNIX TCP/IP host on the remote network: ping 191.1.1.137 If the test is not successful: (1) Ping from the UNIX host to the NetWare fileserver: "ping 191.1.1.140". If this does not work go to step two to resolve the problem. After the UNIX host has successfully pinged 191.1.140, go to step three. (2) Check the addressing on the fileserver, verifying that the correct network address has been assigned to the second board (191.1.1.140) in the fileserver. (If the second board is physically attached to network 191.1.1.128 with a subnet mask of 255.255.255.192 (FF.FF.FF.C0), the address of the board on the fileserver needs to have an IP address and subnet mask that is legal for the 191.1.1.128 network.) (3) Ping from the UNIX host to the board in the fileserver that is attached to network 191.1.1.32, "ping 191.1.1.60". If this does not work proceed to step four. (4) Verify that the routing is configured correctly on the UNIX host by making sure that IP packets can be routed to the NetWare fileserver - that the host at 191.1.1.140 (the NetWare fileserver) is recognized as the router to route packets from network 191.1.1.128 to network 191.1.1.32. On a UNIX system, the general command is: ROUTE ADD For the UNIX host you are working with, check the manual pages for the exact syntax for adding routes. In this example, the command would be: ROUTE ADD 191.1.1.32 191.1.1.140 1 This route command says that if there is a packet that is to be routed to network "191.1.1.32", send it to the router at address "191.1.1.140" that is only one hop away (the packet has to be forwarded through one router to get to its remote network destination). To assign the NetWare server (IP address of 191.1.1.140) as the default router for the UNIX system, in order to route packets destined for any network other than the local, the command syntax would be: ROUTE ADD 0.0.0.0 191.1.1.140 1 If there are other non-NetWare TCP/IP routers on the network, verify that those routers support RIP. The NetWare TCP/IP router supports only RIP. If the other routers do not support RIP, then static routes have to be added at all routers. Configuring static routes for the NetWare TCP/IP router is explained in page 6-27 of the "NetWare TCP/IP Supervisor's Guide". NOTE: If routing is configured correctly on one network but not on the other, packets may be sent to a host on the remote network but the remote host will not be able to route the packets back. In this example, the LWPD workstation may have the correct routing entries in the NET.CFG file (resulting in the ping packet being correctly sent to the UNIX host on the remote network), but the UNIX host does not know how to route the packet back because it does not have a ROUTE ADD command set up. After the above steps have been completed, and routing has been configured correctly on both networks, hosts on one network should be able to ping hosts on the remote network. At this point you have finished testing the configuration of NetWare 3.11 TCP/IP. APPENDIX A - TOKEN RING SOURCE ROUTING ---------------------------------------- A.1 - SOURCE ROUTING CONFIGURATION on the NETWARE FILESERVER -------------------------------------------------------------- To route IP packets through IBM source routing bridges you need to enter the following commands in the AUTOEXEC.NCF file: LOAD ROUTE BOARD=01 LOAD ROUTE BOARD=02 NOTE: These LOAD statements need to be entered in the AUTOEXEC.NCF file after the LOAD and BIND commands that are required to configure NWTCP. ALSO NOTE: The board numbers listed in the load statements are logical boards. This will enable IPX (logical board 1) and IP (logical board 2) frames to go through the IBM source routing bridge. To determine the value to assign to the "LOAD ROUTE BOARD=#" command: - at the NetWare console prompt enter LOAD TCPCON - then select Locate the entry(ies) for the Token Ring LAN driver and note the logical board numbers in order to add them to the LOAD ROUTE command. For more information refer to the "NetWare 3.11 System Administration" guide on page 224 through 229. A.2 - SOURCE ROUTING CONFIGURATION ON A WORKSTATION -------- ------------------------------------------ If you are using source routing on a LWPD workstation, specify the following commands in the AUTOEXEC.BAT file: LSL LANSUP (or TOKEN) IPXODI ROUTE BOARD=1 ROUTE BOARD=2 NETX The ROUTE.COM is loaded twice because both frame types (IPX and IP) require source routing and each appears as a separate board to LSL. NOTE: The values for the ROUTE.COM command in the AUTOEXEC.BAT file are determined by the values in the AUTOEXEC.NCF file on the NetWare 3.11 fileserver. For example if the AUTOEXEC.NCF file contains "LOAD ROUTE BOARD=4" and "LOAD ROUTE BOARD=5", then the entries in the AUTOEXEC.BAT file on the LWPD workstation would be "ROUTE BOARD=4" and "ROUTE BOARD=5". For more information refer to the "NetWare ODI Shell for DOS" guide, on pages 37 through 44 of Appendix A (Using the IBM Token-Ring Source Routing Driver). APPENDIX B - INFORMATION TO PROVIDE WHEN PLACING A TECHNICAL SUPPORT CALL --------------------------------------------------------------------------- When calling your Novell Reseller, Novell Technical Support or posting a NetWire message, please provide the following information: - The IP address of your local host. - The IP address of a remote host. - The IP addresses of the two (or more) interface cards in the NetWare 3.11 fileserver. - The subnet mask for both the local and remote networks. - Information from the NET.CFG (LWPD) file. - Information from the AUTOEXEC.NCF (NetWare 3.11 fileserver) file. - Information from the NetWare console command "CONFIG". - Test results from the "ping" command (from the tests outlined in section IV above). - "root" access to any UNIX systems that might be involved in the configuration. - "SUPERVISOR" access to the NetWare fileserver. To receive technical support, contact your local Novell Reseller and request support. (Your Novell Reseller may want to work with Novell directly, since your reseller may not incur a fee.) For support on NetWire, post questions in NOVA section 8 (NetWare NFS/TCP). (If you do have a CompuServe account, call CompuServe at 800-524-3388 or 614-457-0802 and ask for operator 200. To place a call with Novell Technical Support call 800-NETWARE (800-638-9273) or 801-429-5588 for international. (If the issue is determined to be a software bug not previously reported, there is no charge for the support call.)