--------------------------------------------------------------------------------
                  TECHNEWS:  FEBRUARY '90 EDITION

SunFLASH Vol 15 #11 					 March 1990 
--------------------------------------------------------------------------------

Technews is a service provided by the Sun technical suport staff.
It is intended for use by Sun system integrators and is provided
for your information. -johnj

--------------------------------------------------------------------------------
			C O N T E N T S
I. 	NFS
	A. NFS mount options explained: retrans, timeo, and intr
	B. NFS File Handles

II. 	Sun386i
	A. TOD PATCH

III. 	Advantages of Automounter

IV. 	PCNFS
	A. Overcomming the Network Drive Limit

V. 	Sunview Error Messages Evaluated
	A. window input queue overflow
	B. Request to current holder failed: RPC: Timed out
	C. zs3:  silo overflow
	D. memory buffer is full
	E. valloc failed

VI. 	Second Ethernet controllers on SparcSTATION 1s

VII. 	man strcmp

VIII.  	Putting an SS1 on a 386i Network

IX. 	Adding a Second Disk to the SS1

X. 	Helpful Hints on Subnetting

XI. 	Expanding Environmental Space in the Sun386i DOS Windows

=======================================================================
I. NFS

A. NFS mount options explained: retrans, timeo, and int
-------------------------------------------------------
 
The followiing explanation of mount options may be helpful.

retrans = the number of times a request is sent to the NFS server before
the request times out.
   
timeo = the time to wait *BETWEEN* retransmissions of a request, before
sending another request.  This value is used for all retries specified by 
retrans.  If the filesystem is hard-mounted, then this value is backed-off 
by a factor of 2 (up to a maximum of 30 seconds) before the next set of     
'retrans' requests. See the picture below.
 
intr = allow keyboard interrupt (like ^C) on a hard mount *AFTER* you have 
sent all the requests that retrans specifies, and before you start the 
'send request' sequence all over again. This is also the point at which a 
soft mount would give up.
 
Here's a picture of how these things interact on an rpc call, with a hard
mount vs soft mount. All this stuff is happening on the 'client', but the
requests are going to the 'server' side.
==================================================================
 
   CLIENT SIDE                                     SERVER SIDE
 
   rpc call "lookup"
         --->> callrpc  ----send request---->
         |               \
         |                timeo = n tenths of second
         |               /
         | retrans=     ----send request---->
         | how many      \
 >       | times the      timeo
         | same request  /
   hard  ^ is sent before----send request---->
   mount | timing out    \
 > path  |                timeo
         |               /
         |              ----send request---->
         |
         <<-request times out---- <<intr possible (only time intr can happen)
         | (have sent 'retrans' number of requests)
 >	|  If hard mount, then:  timeo=MAX(timeo << 2, 300)
   soft  v
   mount |
   path  -->>ETIMEOUT
 
 > Note that as timeo grows, it takes longer for intr to take effect.  At the
 > maximum backed-off timeout, it could take up to two minutes for an
 > interrupt to be noticed.

	*** 

B. NFS File Handles

Q:  How do NFS handles become stale?

I can't suggest all the circustances that this could happen, but more
generally I can describe why this stale file handle condition can
happen.  You might think of a client file handle as the key to
accessing the server file.  When a nfs client requests access to a
server file the server returns a file handle which contains the key to
this file (i.e. file location information).  As long as the client is
accessing this file the file handle should be good.

However, if while the client has this file handle something happens to
change the inode assignment of this file on the server, then when the
client next tries to access this file using the "now stale" file handle
info this error results since things have changed.  Without file
locking this can commonly happen if during shared access to the file
the file gets, deleted, renamed, etc.., while others also currently
have file handles to it.   One other case could be if a common nfs
mounted client /tmp directory is shared from a server and the /tmp
directory gets wiped out and destroys some client tmp files currently
in use (vi, textedit, etc..).  Otherwise perhaps some disc controller
problems could also affect this condition, and even some clock skew
between client and server may cause this (use rdate).

=======================================================================
 
II. Sun386i

A.  TOD PATCH 

Clock drifts on the sun386i, screenblank will not unblank.

There is a known problem with the Sun386i Time-of-day (TOD) chip which
causes it to *gain* time.

When bit 7 of the day register is set, the time under UNIX will gain
approximately 15 minutes every hour.  If the machine is shut off it
will gain even more time.
 
If your machine is *gaining* time, look at the contents of the day
register first to see what it contains.  Type at the prom monitor:
  
 >q 7fc
  
to do this.  It should contain a 0X (X= anything).  If the first digit
is anything other than zero, you should follow the procedure below.
  
The fix for this problem is (from the prom monitor):
 
 >q 7f8=80       sets the write bit
 >q 7fc=0        sets day register to 0
 >q 7f8=0        clears the write bit
  

=======================================================================

III. Advantages of Automounter

If you do not use an NFS filesystem, and its NFS server crashes, your
machine won't hang, so that is no big advantage of the automounter.
The problem is that you can touch that NFS partition in ways that you
wouldn't expect or don't intend, such as starting a new emacs in a
different directory, or typing "df" instead of "fg".
However, sometimes you do use a filesystem without to much attention (ls
-R, find).

The automounter has some more advantages from a system administration point 
of view.

First of all, the automounter is capable of selecting an NFS server in
cases where several servers can provide the same file system. The entry in
an automount map may have the form:
	man1	ajax:/usr/share/man/man1  hercules:/usr/share/man/man1 .....
 	man2	zeus:/usr/share/man/man2  poseidon:/usr/share/man/man2 .....
	......
Note that this selection is made for almost every access of a man-page.
 
Second, the automounter can give the suggestion of one directory, in case
the subdirectories are physically different directories on different
machines.  This can be done by normal mounts too, though the advantage of
the automounter is the fact that you don't have to create empty
subdirectories as mountpoints. 
 
Third, the automounter can make local/NFS filesystems available by a
number of paths: the automounter (will/tries to/should/can be instructed
to) avoid duplicate mounts. It creates and destroys symbolic links to
mounted file systems.
 
Fourth, the automounter creates a dynamic indirection between "virtual
place" and "physical place" of a directory.  The best example I know of is 
the auto.home map on the 386i. Users think of their home-directory as
"/home/fred", "/home/susan" etc. Even in the password file their home
directories are specified like this.
 
So in cases of "disk-space-reorganisation" (every administrator knows what
I mean: disk shortage and system crashes ...) the only two things I have to 
do is:
	- move things around
 	- update the "auto.home" automount map. 

When all users should write their scripts, and .files using $HOME or
"~",  they shouldn't care about moving around ... however, they don't.
 
Fifth, automount maps can be (will almost always be) distributed by YP.
This is not true for fstab, so imagine the work which is involved in the
previous case of moving home directories.
 
Sixth, some default automount maps can be available. Currently
 	automount /net -hosts
will mount the complete local tree of a machine you know when needed (i.e.
at the moment of accessing /net/machinename).


=======================================================================

IV. PCNFS

A. Overcomming the Network Drive Limit

The 8 drive limit in PC-NFS is a fixed and non-artificial limit,
due to the structure used to store the internal drive specifier
(it's a one byte variable).  
 
There is no method for overcoming this limit, but the preferred work 
around is to write a DOS batch routine to dismount one drive and
remount another, like this:

DRIVSWAP.BAT:
 ECHO OFF	
 REM  Usage:DRIVSWAP [DRIVE_TO_DISMOUNT] [DRIVE_TO_MOUNT] [\\HOST\DIRECTORY]
 NET USE 1% /D
 NET USE 2% 3%

Then if the user wants to replace G: with H: they can type:
 DRIVSWAP G: H: \\[hostname]\[directory]
 


=========================================================================

V. Sunview Error Messages Evaluated

	***

A. Question:  What does "window input queue overflow" mean?
 
A customer is having problems with a SCSI disk and at the same time that
he is seeing other errors, he sees:

		window input queue overflow
		window input queue flushed

Can one of you shed more light on what these messages mean?  
 
Ans:  
User actions like typing on the keyboard and clicking the mouse are
known in SunView parlance as "events."  Being that hardware is managed
by the kernel, it is the kernel which translates user activities into
events which it then passes to its window devices, e. g. /dev/win42,
and eventually to the process owning the window.
 
It is this flow of events that these two error messages refer to.  As
with silo overflows, the indication is that a kernel buffer has become
too full, something which can have one of two causes:  (1)  events
are being sent to the window too quickly or (2) events are not being
taken out of the queue quickly enough.

(1) is generally rare, but I imagine might be possible if they've done
something very strange to their kernel; far more likely is (2) whose
likely cause is that the process which is to handle the events has stopped
or died.  In fact, in my mind, the single most common time to see these
messages is that suntools itself has died, while some of the other
applications continue to run as best they can (which is not very well).
 
Thus, these messages are usually symptomatic of other problems, i. e.
processes mysteriously hanging or going away, rather than an indication
of windows problems per se.
 
	***

B. Question: What does, "Request to current holder failed: RPC: Timed out", 
mean?

Ans:  That is a message from the selection service which uses RPC calls.
For some reason, the RPC call has timed out.  Could be network or CPU load
on the machine or a race condition in the selection service where one window
is trying to notify the Selection Service that it has the primary
selection, meanwhile another window is asking the Selection Service
"Is there a primary selection right now?"  These two simultaneous requests
collide resulting in the time out of the RPC calls used by the selection
service.

If the race condition is the problem, then one can use the secondary selection
instead of the primary selection. i.e. hold down L8 while selecting text.
Instead of inverse video, one would see an underline.

Can also be a symptom of a network problem...see rpc_timed_out_4.0
 
If they cannot get any selections, most likely they have their network
configured incorrectly.  i.e. they need loopback networking on a standalone
host.
 
	***

C. Question: What does the error message "zs3:  silo overflow" mean?

Ans:  The "zs3" part refers to the mouse driver.  (zs2 is the
keyboard and zs1 and zs0 are serial ports ttyb and ttya
respectively.)
   
The mouse driver has a limited buffer, or silo, in which 
to store mouse input events.  If there are more events
than the buffer can hold, some events are lost and this
message is printed.

It is very unlikely that a user could generate mouse input
quickly enough to overflow the buffer, so this message
usually means that for some reason applications are not
taking mouse events out of the mouse driver quickly enough.
Possible reasons can include:  (1) a very sluggish system
(perhaps due to insufficient memory or network problems),
(2) the suntools window manager process having died while
windows remain up or (3) hardware problems.
     
So while this error message is not serious in and of itself,
it may point to other system problems.

	***

D.  Question: What does it mean when I get the message, "memory buffer 
is full" in textedit/textsw.
 
Ans:  A text window cannot have more than 20000 characters inserted into it
unless you are editing a file or increase the attribute TEXTSW_MEMORY_MAXIMUM
via defaultsedit or window_create().  To get rid of the message, click 
until the last message goes away, then save to a file.  The textsw can
become arbitrarily large when saved to a file.

	***

E. Question: Window tool failed to come up, got "valloc failed" message
 
 > pr_makefromfd error: valloc failed
 > pr_open: pixrect create failed for /dev/fb
 
Answer:  There was not enough swap space on the machine to start the tool.
For example, in order to paint the screen,
"lockscreen" (and any other SunView program) has to map the frame buffer
into its address space.  In order to do that, it first has to allocate a
chunk of memory the same size as the frame buffer, and then map the frame
buffer on top of it.  Once the frame buffer is mapped, that chunk no longer
requires any swap space (unless you've mapped something else on top of a
chunk of memory already, which is unlikely); however, until it is mapped, it
*does* require swap space.

You probably ran out of swap space, so it couldn't allocate memory to map
the frame buffer on top of.  Swap space for data is allocated in chunks that
get bigger the larger your data space gets; the swap space can get
fragmented, so that a chunk of the required size may not be available, even
though there are enough pieces of swap space to make up the required size.
Exiting "suntools" frees up swap space, so that the various pieces may no
longer have allocated pieces between them; thus, when you re-enter
"suntools", you may now have enough contiguous swap space to run
"lockscreen".
 
If this becomes a continual problem, increase your swap space.


========================================================================

VI. Second Ethernet controllers on SparcSTATION 1s

Some customers have called in inquiring if they can use a second 
ethernet card as the primary ethernet port so that they can use 
thinnet instead of thicknet.  

We do not support this configuration.  The second ethernet card is used
for gateways only.  They should be getting thick to thin transceivers.
It's less expensive and easier to install.  The second ethernet card
generates all kinds of strange errors.

=======================================================================

VII. man strcmp

With the sunos4.0.3c, if you type man strcmp you would get this error mesage,

Can't find referent of .so in /usr/man/man3/strings.3

The reason behind this is because the 4.0.3c is missing strings.3 under
/usr/man/man3, the work around is get a copy of strings.3 from sunos4.0.3
and put it in /usr/man/man3.

=======================================================================

VIII.  Putting an SS1 on a 386i Network

When specifying the domain name for the SparcStation 1's, you need to
enter it as YP.<domain>, where <domain> is the name you typed for the
domain on the 386i master.

The best way to check to see what the domainname is on the network is to
type the "domainname" command on the 386i NIS(formerly YP) master server.
Usually you will get something back in the form of "YP.<domain>".

=======================================================================

IX. Adding a Second Disk to the SS1

A bunch of the VARs are getting SparcStation 1's with only 1 internal disk
and then at a later time installing a second 104Mb internal disk.  The problem
they run into is that they format this second disk and then try to mount it.
They must first run the newfs command on the partitions setup on that second
disk:

# newfs -v /dev/rsd1g

is one example of having just one data partition(g) on that second disk.

========================================================================

X. Helpful Hints on Subnetting 

Setting Up a Subnet

Application

       Sun3/SunOS3.5, Sun4/SunOS3.5
       Sun3/SunOS4.0, Sun4/SunOS4.0, Sun386i/SunOS4.0
       Sun3/SunOS4.0.X, Sun4/SunOS4.0.X, Sun386i/SunOS4.0.X

Synopsis

       The procedure for converting a nonsubnetted  network  into  a
       subnetted network.

Keywords

       subnet network class address internet netmask

Prerequisites

       Read and understand all sections in `Explanation' below.

Procedures

	The following procedure outlines the  general  steps  for
	converting  a nonsubnetted network over to a subnetted one:

1.	Decide on new network/subnet topology:

	*   Decide on how many separate physical subnets.

	*   Choose machine/s to act as routers between subnets.

	*   Decide on locations for hosts on subnets.

	*   Decide how many bits in ip address will be used for the
	    network number.

	*   For  example,  currently  we  have  class  B  network
	    address 129.145.0.0.   We  have a total of 50 machines.
	    Our goal is to split network into 2 subnets.  In this
	    case,  `snowwhite'  will act  as router machine between two
	    subnets.  The 28 machines on floor 3 will be on one subnet,
	    and the  other  22  machines  on floor  4  will  be on
	    another.  We will use 24 bits for network number 
	    (netmask = 255.255.255.0)

2.	Assign all subnet and host addresses.

	For example, the two subnets will be 129.145.14  &
	129.145.15.   On the  gateway  machine  the ie0 ip address
	will be 129.145.14.1 using hostname `snowwhite', and the ie1
	ip address will  be  129.145.15.10 using hostname
	`snowwhite-rt'.

	All hosts attached to the same physical subnet associated
	with  the snowwhite  ie0  interface  should  be assigned
	their own unique host number, for example, host `happy'
	might  be  assigned  the  address 129.145.14.2, and so
	forth.

	All other hosts attached to the same physical subnet
	associated with the  snowwhite-rt  ie1  interface  should
	be assigned a unique host address for that 129.145.15 net.
	For example, host `dumbo' might be assigned the address
	129.145.15.11.

3.	Change /etc/hosts file on each machine to reflect all the new 
	ip addresses.

	For example, on `snowwhite', the /etc/hosts should include:

		127.0.0.1       localhost
		129.145.14.1    snowwhite loghost   # ie0 network
		129.145.14.2    happy
		129.145.15.10   snowwhite-rt        # ie1 network
		129.145.15.11   dumbo


	It should be noted that the `127.0.0.1 localhost' entry
	should  not be  changed  or  deleted.   Also, the `loghost'
	alias is arbitrarily assigned.  If YP will not be  used
	each  machine  can  be  its  own loghost  by aliasing
	loghost to the hostname of that machine such as in the
	example below of a /etc/hosts file for the host `happy':

		127.0.0.1       localhost
		129.145.14.1    snowwhite           # ie0 network
		129.145.14.2    happy  loghost
		129.145.15.10   snowwhite-rt        # ie1 network
		129.145.15.11   dumbo

	Because some host lookup problems could occur under YP if
	upper case letters  are  used  in  hostnames,  it  is  best
	to  always use all lowercase hostnames in all files where
	hostnames are used.

4.	If YP is used be sure the  /etc/hosts  file  on  the  YP Master  
	is accurate and complete, then update the YP database.

	   For example, on ypmaster do the following:
		# cd /var/yp
		# make

5.	If there are diskless clients on the net (traditionally setup on 
	the server's  ie0  interface  network),  make  sure that on the 
	server /usr/etc/rarpd is running on  that  network interface.   

	Also,  the /tftpboot directory on the server
	contains symbolic links associated with the client IP address
	(in hexidecimal).  These links must  also be changed to reflect
	new subnet addresses.

	The if host `happy' (129.145.14.2) is a Sun 3/60 diskless
	client the server's /tftpboot entry should be:


	lrwxrwxrwx  1 root 9 Oct 11 08:13 81910E02 -> boot.sun3


	For more information on diskless setups, see the section on
	`Booting over   the   Network'   on  page  40  of  the
	`System  and  Network Administration' manual, part number
	800-1733.

6.	On each machine, set up the netmask.  This can be done by one of 
	two procedures:

	*  Edit /etc/netmasks to include the  network  and
	   netmask.   For example, on each host, /etc/netmasks:

		129.145.0.0 255.255.255.0


	   On each host the standard  /etc/rc.local  should
	   already  have appropriate ifconfig lines such as:

		 /etc/rc.local:
		 ifconfig ie0 `hostname` netmask +
		 ifconfig le0 `hostname` netmask +
		 ifconfig ec0 `hostname` netmask +

	   For gateway machines an additional ifconfig line  for
	   the  ie1 interface should also be added.

	   When using YP be sure the Master has an accurate
	   /etc/netmasks file then update the YP database.

	   For example, on ypmaster:

		     # cd /var/yp
		     # make netmasks


	   This  method  is  documented  in  the   `System   and
	   Network Administration' manual, part number 800-1733.

	*  If problems should occur  with  the  above  method  of
	   netmask lookup  you  may  instead  use explicit ifconfig
	   entries in the /etc/rc.boot file and comment out the
	   ifconfig  lines  in  the /etc/rc.local file.

	   Edit /etc/rc.boot and add the  subnet  mask  to  the
	   ifconfig.  Comment  out  the ifconfig lines in
	   /etc/rc.local. For example, on `snowwhite', do the
	   following:

		     /etc/rc.boot :
		     ifconfig ie0 $hostname -trailers up netmask
		     255.255.255.0
		     ifconfig ie1 snowwhite-rt -trailers up netmask
		     255.255.255.0


		      /etc/rc.local :
		      #ifconfig ie0 `hostname` netmask +
		      #ifconfig ie1 snowwhite-rt netmask +

		      On `happy',
		      /etc/rc.boot :
		      ifconfig ie0 $hostname -trailers up netmask
		      255.255.255.0

		      /etc/rc.local :
		      #ifconfig ie0 `hostname` netmask +


7.	Reboot all machines.

8.	You  should  verify  the  correct  IP  address, netmask, and broadcast 
	address  is now in use by using the ifconfig command with the interface 
	type as the argument.

	For example, on `snowwhite':

		# ifconfig ie0
		# ifconfig ie1


Detailed Explanations

       Subnets are logical subsections of a single Internet network,
       therefore it  is  first  necessary  to  understand  the Internet
       addressing scheme before trying to grasp  the  concept  of
       subnetting.   If  you  already understand  Internet
       addressing,  go  on to the section on `Subnetting' below.

Internet Addressing Scheme:

       Every site requires its own unique Internet number.  These
       numbers  are administered  and  assigned  by the Network
       Information Center at SRI in Menlo Park, California.  See the
       `System  and  Network  Administration' manual,  part  number
       800-1733,  Section  12.3  `Obtaining  an Internet Number' for
       more information on obtaining Internet numbers.

       Each IP address is composed of a 32 bit number which is broken
       down into 2 parts, the network address and the host number.
       Typically IP addresses are displayed in a  format  which
       breaks  the  address  into  4  fields separated  by a period
       (i.e 192.9.200.1) where each field represents the decimal value
       for 8 bits.

       Basically there are three primary classes  of  IP  addresses
       which  are traditionally assigned for network use:

Class A:

	 First field is the network address, and last three represent
	 the  host address, with the ranges for each field being:

	      [1-127].[0-254].[0-254].[1-254]

	 For an address of 127.0.0.1

	 binary = 01111111.00000000.00000000.00000001
	 network address = 127
	 host address    = 0.0.1


	 The 127 network address is actually reserved for special
	 purpose.   As noted previously, SunOS uses it for it's
	 loopback interface address.

Class B:

	 First 2 fields are the network addresses and the last 2 are
	 the  host addresses, with the ranges for each field being:


	      [128-191].[1-254].[0-254].[1-254]

	 For an address of 129.25.10.2

	 in binary = 10000001.00011001.00001010.00000010
	 network address = 129.25
	 host address    = 10.2


Class C:

	 First 3 fields are the network addresses and the last 1  is
	 the  host address, with the ranges for each field being:

	      [192-254].[1-254].[1-254].[1-254]

	 For an address of 192.9.200.11

	 in binary = 11000000.00001001.11001000.00001011
	 network address = 192.9.200
	 host address    = 11


	 Notice the first 2 bits actually determine what class the
	 address is:

	      01 - class A
	      10 - class B
	      11 - class C


	 Also note that IP broadcast addresses are contructed by use
	 of  0  or 255  address  numbers.   As  a  rule  for normal
	 host assigned network addresses, the network byte and the last
	 host address bytes should  be neither 0 nor 255.

	 Examples of incorrect host assigned IP addresses are listed
	 below:

	      0.0.10.1      (0 in network field)
	      255.0.10.1    (255 in network field)
	      192.9.200.0   (0 in last host field)
	      192.9.200.255 (255 in last host field)


	 Examples of correct IP addresses are listed below:

	      128.0.0.1
	      155.44.0.11
	      200.10.50.5


Subnetting

	 Subnetting is basically  the  process  of  breaking  up  one
	 Internet network  into  smaller networks (subnets) for either
	 administrative or technical reasons.

	 Since getting official Internet numbers is  becoming  more
	 difficult, subnetting provides a way of getting more network
	 addresses out of one official classA, classB  or classC
	 network address (although  class  C nets are rarely
	 subnetted).

	 For a large network, subnetting can make routing  more
	 efficient  and can  ease  administration.  A good analogy is
	 the phone network: phone numbers are broken down by area code
	 and then by prefix  to  make  the job  easier  for  routing
	 a  particular  phone  call  to  the correct location.  Can you
	 imagine how difficult it would be  if  everyone  in the U.S.
	 just had one random 10 digit phone number?

	 Subnetting is accomplished by use of a  32 bit `netmask',
	 which  masks off  the  network  address  when  `anded'  with
	 the  IP address.  For instance, a netmask of 255.255.255.0
	 will mask off the first 3  fields for the IP address:

	IP address: 11000000.00001001.11001000.00001011
	netmask: 11111111.11111111.11111111.00000000
	perform logical 'and': -----------------------------------
	network address: 11000000.00001001.11001000.00000000

	 This is the default netmask for Class C addresses. The default
	 netmask for  Class  A addresses is 255.0.0.0.  The default
	 netmask for Class B addresses is 255.255.0.0.  And unless
	 another subnet mask is set,  the system will automatically use
	 these defaults.

	 Subnetting works by using a netmask other than the default to
	 use more bits for the network address than is normally
	 determined by its class.  For example, say we have a class A
	 network address of 24.   A  typical IP  address  on  this net
	 might be 24.0.0.11, where the host number is 0.0.11.



	   |----------------------------------------------------------|
	   24
	     |(ie0)           | (ie0)
	      `happy'     `doc'
	     24.0.0.11      24.0.0.15

	 We would like to split this  net  into  two  different
	 networks  (two actual  physical networks separated by a router
	 machine which connects via ie0 to one subnet and via ie1 to
	 the other).   With  the  first  8 bits  being  set  at  24
	 (the 'official' assigned network number), in order to get 2
	 network numbers, we need to use more bits from the host
	 field/s  for  the  network  address.  A common subnet mask for
	 Class A addresses is 255.255.0.0,  which  uses  the  second
	 field  to  obtain multiple  network addresses (therefore,
	 suddenly 24.1, 24.2, ...24.255 become available network
	 addresses).

	      netmask = 255.255.0.0.
	  |-----------------------------------------------|    24.10
		 |(ie0)       |(ie0)
		 |            |
	      24.10.0.1        24.10.0.2
	      `snowwhite'       "doc"
	   `snowwhite-gateway'--> 24.11.0.12
		 |
		 |(ie1)   netmask = 255.255.0.0
		       |----------------------------------------|
		       24.11
		      |(ie0)
		      24.11.0.8
		       `happy'



Using NonByte-aligned Netmasks:

	 Although it is common  to  set  netmasks  on  the
	 byte-aligned  field boundaries  (i.e.  255.255.0.0 and
	 255.255.255.0), netmasks can be any number of bits.  An
	 example of a valid subnet mask is:

	 255.255.248.0   in binary: 11111111.11111111.11111000.00000000
	     (Uses first 21 bits for network number)

	 However, caution should be used when using non-byte aligned
	 netmasks.  For  instance,  if  we  used  the above netmask for
	 a Class B address, 129.145.0.0, and we choose 129.145.8 and
	 129.145.9 for  subnets, then we have the following bit
	 configurations:

	 129.145.8 10000001.10010001.00001000.00000000
	 apply the netmask: 11111111.11111111.11111000.00000000
	 Resulting network address:   10000001.10010001.00001

	 129.145.9 10000001.10010001.00001001.00000000
	 apply the netmask: 11111111.11111111.11111000.00000000
	 Resulting network address: 10000001.10010001.00001

	 Notice that the  resulting  network  addresses  are  the
	 SAME,  which creates ambiguity and confuses routing.

	 We must be careful to choose network addresses that will be
	 contained in  the  bits  masked  by the netmask (in the 5 high
	 order bits in the above example):

	 nnnnnnnn.nnnnnnnn.sssss hhh.hhhhhhhh
	 129.145.24  10000001.10010001.00011000.00000000
	 129.145.56  10000001.10010001.00111000.00000000
	 129.145.32  10000001.10010001.00100000.00000000
	 etc...


Subnetting `Do's & Don'ts'

1.	Use consistent subnet masks.

	     One key rule about subnetting is that the netmask must be
	     the same for subnets which are derived from the same
	     network number.

	     For instance, the following configuration would be
	     incorrect:

		  netmask = 255.255.255.0.
	      |-----------------------------------------------|
	      24.10.3  <--|
		     |(ie0)       |(ie0)           |
		     |            |            |
		  24.10.3.1        24.10.3.2        different
		  `snowwhite'       "doc"       netmasks!
		   24.11.0.12                  |
		     |                         |
		     |(ie1)   netmask = 255.255.0.0    |
			   |----------------------------------------|
			   24.11 <--|
			  |(ie0)
			  24.11.0.8
			   `happy'


	     However, the following network would be correct, since the
	     subnets are derived from DIFFERENT network numbers:


		  netmask = 255.255.0.0.
	      |-----------------------------------------------|
	      24.10       <--|
		     |(ie0)       |(ie0)              |
		     |            |               |
		  24.10.0.1        24.10.0.2        derived from
		  `snowwhite'       "doc"      different network
		      129.145.2.10                       numbers
		     |                            |
		     |(ie1)   netmask = 255.255.255.0     |
			   |----------------------------------------|
			   129.145.2 <-|
			  |(ie0)
			  129.145.2.8
			   `happy'

2.	Do not put subnets on same physical network.

	     Subnets  must  be  physically  separated  by  a   router
	     machine (`snowwhite'  in these cases).  Two subnets cannot
	     be mixed on the same physical network.  The following
	     network is incorrect :

		      netmask = 255.255.0.0
		  |----------------------------------------------------|
		  (24.10 &
		  |(ie0)          |(ie0)      |(ie0)    24.11 may
		      `happy'     "doc"   "sleepy"      not reside
		  24.10.0.11    24.11.0.15    24.11.0.16  on same
		  cable)

	     This complicates routing and defeats the purpose of
	     subnetting.


References


       See the `System and Network Administration'  manual,  part
       number  800-1733, Chapter  12:  `Setting  up  Subnets,'  pages
       302-304 for more information.   See the following manual pages
       for more information also:

	       hosts(5)
	       netmasks(5)
	       ifconfig(8C)
	       routed(8C)
	       netstat(8C)

       For current information on Internet, contact:

	   	SRI International (SRI-NIC)
	   	DDN Network Information Center
	   	333 Ravenswood Avenue
	   	Menlo Park, CA 94025
	   	(415) 859-3695 (800) 235-3155



Support Guidelines

       Be sure you fully understand subnetting concepts  and  are
       prepared  to completely   subnet   a   network   using  a
       common  base  IP  address.  Inappropriately or incompletely
       administered  subnet  environments  can create  some  very
       severe  and  immediate  problems  with network-based services.

When A Machine Cannot Communicate with Others on the Subnets:

       One of the most common problems which occurs on a subnetted
       network  is that  certain  workstations fail to set their subnet
       masks correctly and thus have difficulty communicating with
       other machines  on  the  various subnets.   This  often
       happens  as  the  result  of a re-install of the operating
       system where the /etc/netmasks, /etc/rc.local and /etc/rc.boot
       get overwritten and are not re-editing to set the subnet mask
       correctly.

       In this case, error messages you might see when trying to
       access  other machines on the various subnets are:

	    Send to:  Network is unreachable
	    Connection timed out


       If a computer is having difficulty communicating with other
       machines  on the various subnets,  check the following:

1.  	Look at the current routing tables with netstat(8C):

	For example, if the subnet mask is not set correctly, here
	is  what you might see:

	       # netstat -rn
	       Destination  Gateway             Flags   Refcnt Use  Interface
	       127.0.0.1    127.0.0.1           UH      1      91   lo0
	       129.145.0.0  129.145.19.7        U       5      86   le0

	Note that the above 129.145.0.0 entry doee not distinquish
	subnets and would an attempt to reach a non-local subnet
	address destination (such as 129.145.20.1) would fail. 

	If it is set correctly, you should see more entries representing
	actual subnet destinations and associated gaetway like:

	       # netstat -rn
	       Routing tables
	       Destination      Gateway         Flags    Refcnt Use  Interface
	       127.0.0.1        127.0.0.1        UH       1     91   lo0
	       129.145.1.0      129.145.30.21    UG       0      0   le0
	       129.145.19.0     129.145.19.7     U        5     86   le0
	       129.145.20.0     129.145.30.21    UG       0      0   le0
	       etc...

2.	If the routing tables do not look right, then check current netmask  
   	with ifconfig(8C):

	   For example:

		for le0 interface:
		    # ifconfig le0
		    le0: flags=63<UP,BROADCAST,NOTRAILERS,RUNNING>
		    inet 129.145.19.7 netmask ffff0000 broadcast 129.145.0.0


	Notice that the default class B (ffff0000) subnet mask is
	set.  If we are subnetting, a nondefault mask should be
	set such as ffffff00.

3.	If the subnet mask has not been set,  perform  step  6
	outlined  in above  procedure  to  set  the netmask correctly
	and then reboot the machine.

==========================================================================

XI. Expanding Environmental Space in the Sun386i DOS Windows


There is a bug in the dos window on the 386i where you cannot expand 
the environmental space for dos with dos -c.  A simple work around this bug
is to patch command.com to permanently increase environmental space. The patch
is:

        C:
        cd \
        debug command.com
        -u cs:0f24
        # Output from above command
        16B0:0F24 C706FA160A00  MOV     WORD PTR [16FA],000A
        16B0:0F2A BA4350        MOV     DX,5043
        16B0:0F2D B104          MOV     CL,04
        16B0:0F2F D3EA          SHR     DX,CL
        16B0:0F31 89160417      MOV     [1704],DX
        16B0:0F35 2BC2          SUB     AX,DX
        16B0:0F37 A3DF0B        MOV     [0BDF],AX
        16B0:0F3A A12C00        MOV     AX,[002C]
        16B0:0F3D 0BC0          OR      AX,AX
        16B0:0F3F 7406          JZ      0F47
        16B0:0F41 FE06E516      INC     BYTE PTR [16E5]
        -a 0f28
        # Output from above command
        16B0:0F28 db 20
                  ^^^^^
                 what you type in
        16B0:0F29 ^M
        -w
        -q

This patches location 0f28 from 0a to 20.  By doing this, the environmental
space will be increased from 160 bytes to 512 bytes.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Sunflash is an electronic mail news service from Sun Microsystems,
Ft. Lauderdale, FL. Please address comments to John McLaughlin
(sun!sunvice!johnj or johnj@sunvice.sun.COM). (305) 776-7770.