*******************************************************************************************************************************
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:
  <net><subnet><host>
The <net> part is defined by the IP network address and the <subnet> and <host> 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 <destination network> <gateway address> <metric>
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 <INTERFACE TABLE>
 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.)
 
