[mod.protocols.tcp-ip] SUN and Subnets

medin@ORION.ARPA (Milo S. Medin, NASA ARC Code ED) (08/10/86)

Hi folks.  I'm working on building some IP based networks for NASA, and
in talking with several sites, I've found that many would like to shove
an additiional ethernet board into a SUN fileserver, and gateway the traffic
from the busy local ethernet to a 'backbone' type ethernet.  Further, a couple
places are using Sun's SUNlink package running over 9600 baud synch. lines
linking a couple machines out in remote locations, and would prefer to
continue using it.  The problem I've run into is that SUN doesn't support
subnetting.  We subnet here at Ames, and have some SUNs in the local
internet, but none as gateways.  We can deal with them because our IP
gateways run with the 'arphack' and so we fool the SUNs into working
into the subnet structure of the local network.  But you can't deal with
subnetting if the gateway doesn't know about it.  So I'm faced with swapping
out all the SUN machines being used as gateways with a 'real' gateway, or
using bunches of Class C nets here and there.  Using a more capable
gateway is probably in the future for all the long haul links, but
the campus LAN's will probably continue to use SUN fileservers as gateways
simply because they may have a lot of diskless SUN clusters.

When I asked my SUN rep. about subnetting, he said that SUN OS 4.0 might
have it, and that would be released in the Jan./Feb. '87 timeframe, but would
make no committments.  Other people I know who have asked got no commitment
from SUN at all.  Further, my SUN rep. mentioned that subnetting requires
some non-trivial changes in NFS.  I can't understand why this would be the 
case.  I'm aware that various sites have patched up SUN kernels
to run with subnets, and that it was fairly easy if you had source code.
Many of the sites I talk to however, would really not like for
me to come in with a special set of .o files and start messing
with their working vanilla SUN kernels unless I absolutely had to.  
I can't figure out why SUN is being so tardy about implementing
subnetting.  RFC 950 has been out for some time, and considering
the amount of business they do with universities, I would think many
people would be grateful for some relief in this area.  Has anyone
out there gotten a committment from SUN to implement subnetting,
or gotten any reason why its hard for them to do so?  It sure would
be easier on the Internet community if they did so.  Anybody from
SUN care to comment?


					Milo Medin
					NASA Ames Research Center
					Moffett Field, CA 

			      Internet: medin@ames.arpa
			      UUCP:	{seismo,amdcad}!nike!medin

rick@SEISMO.CSS.GOV (Rick Adams) (08/10/86)

Back in March I got a pseudo answer out of Sun. They would like to
have it in the 3.2 release, but it would probably break the binary backwards
compatibility with 3.0, so they would probably have to wait for 4.0.

From the sound of it 3.2 should really be called 4.0, and 4.0 shold be
called 5.0.

It seems to be more of a marketing decision than an engineering decision.
I'd gladly accept the tiny backwards incompatibility as I'm sure most 
people would.

---rick

karels@MONET.BERKELEY.EDU (Mike Karels) (08/10/86)

Berkeley has been using Suns on subnetted networks and (sigh) as gateways
for nearly two years.  We added subnet support before we even had source
code by substituting 1 kernel source file and 2 header files, plus
ifconfig and routed.  Unfortunately, several Sun changes have made this
harder to support, and the subnet scheme used is the old Berkeley scheme
which supports only 8-bit subnet fields with the high bit set.  I have
been told by Sun systems people that subnet support will be in the 4.0
release, but that's not as helpful as I would like.  I have been tempted
to figure out how to package and distribute subnet support for Suns,
but haven't taken the time to do so.  Perhaps I could convince someone
else working with Suns at Berkeley to package things up if a few sites
could test it.

		Mike

chris@gyre.umd.edu (Chris Torek) (08/10/86)

We just insist on source, so that we can fix things like that (and
like the lack of checksumming in NFS) ourselves.  (We seem already
to have been bitten several times by Ethernet bit rot: `mysterious'
NFS errors that are not reproducible.  There was no other disk
activity at the time, so this is not the namei bug.)

Steve Miller dropped the 4.3 TCP into our 3.0 kernels.  Aside from
one locally-introduced bug, it has been working well for some time.
(The local bug was fixed a few days ago.)  Once the file servers
are stable---we have been suffering with disk problems (another
local hack, this time in hardware)---we might consider distributing
the code; but we will likely have to require both 4.3 and 3.0 source
licenses (alas!).

Chris

paul@UMIX.CC.UMICH.EDU ('da Kingfish) (08/10/86)

maybe Sun would be a little quicker if they realized that one
of their competitors, Apollo, has a very nice tcp release that
includes subnetting.

we are running it here now at Michigan.

--paul

steve@brillig.umd.edu (Steve D. Miller) (08/11/86)

   I've heard a lot of things from a lot of people, and have some things
to say on my own.  Let's see if I can't make a stab at answering some
of the questions here...

   In the first article in this discussion, Milo Medin (medin@ames) says:

	When I asked my SUN rep.  about subnetting, he said that SUN OS 4.0
	might have it, and that would be released in the Jan./Feb.  '87
	timeframe, but would make no committments.  Other people I know who
	have asked got no commitment from SUN at all.  Further, my SUN rep.
	mentioned that subnetting requires some non-trivial changes in NFS.
	I can't understand why this would be the case.

   OK.  From what I have heard, Sun is trying to move to a 4.3BSD networking
base with the 4.0 release.  I have talked to (a) some people at a Sun/LMI
NFS conference held in Boston in April and (b) one of the people supposedly
working on it, and unless I have grossly misunderstood something I believe
that this is indeed the case.  The timeframe for the release sounds right
to me; the 3.0 release is slated for October.  Again, no commitments...but
I did it myself and didn't think it was too hard.  I didn't even have a real
understanding of the networking code at the time I did it and I'm sure that
the Sun people do, so they should have even less of a problem.

   Sun said at the NFS workshop that they were trying to get rid of ND,
and that NFS was going to undergo a protocol rollover with the 4.0 release.
I'm sure that NFS will need a lot of work to allow things like swapping,
but I *know* that NFS version 2 (the one running in 2.0 and 3.0) works
with little or no changes on top of a subnet-based kernel.  I *ran* it
on top of one (see below).  If there's a problem, I'd love to hear what
it is so I can fix it...but I think the rep is wrong on this one.  The
only thing that comes to mind at all is that the kudp_fastsend() routine
used to get kernel RPC/UDP packets onto the wire as fast as possible
takes a number of liberties (like no checksums) with the UDP/IP output
routines and might well need a rewrite for subnets.  Commenting it out
works just as well, though...and I confess that's what I did.

   In another article on the subject, Mike Karels (karels@monet.berkeley.edu)
says:

	I have been tempted to figure out how to package and distribute
	subnet support for Suns, but haven't taken the time to do so.
	Perhaps I could convince someone else working with Suns at Berkeley
	to package things up if a few sites could test it.

   You've got yourself a volunteer.  I don't know how useful I'd be, but I
can try to make sure that the stuff works for gatewaying.  There's a room
here that could stand to be its own network; now if I can just convince my
bosses...

   In yet another article, Chris Torek (chris@mimsy.umd.edu) says:

	Steve Miller dropped the 4.3 TCP into our 3.0 kernels.  Aside from
	one locally-introduced bug, it has been working well for some time.
	(The local bug was fixed a few days ago.)  Once the file servers are
	stable---we have been suffering with disk problems (another local
	hack, this time in hardware)---we might consider distributing the
	code; but we will likely have to require both 4.3 and 3.0 source
	licenses (alas!).

   Well, I haven't really done all that yet.  I had all of the 4.3BSD (beta!)
networking code, including XNS and a protocol-independent version of NFS, in
a local kernel based on Sun 2.0.  It ran subnets to the same extent as the
4.3BSD beta release, and NFS didn't hiccup at all.  As I said though, I did
comment out the one (relatively small) piece of code that did the fastsend
stuff.  I will probably start work on the 3.0-based version in the next
week or two, and we will probably let it out (with licensing restrictions
like I stated above) once it seems stable.  I don't know if "distribute"
is the right word...

	-Steve

Spoken: Steve Miller 	ARPA:	steve@mimsy.umd.edu	Phone: +1-301-454-1516
CSNet:	steve@umcp-cs 	UUCP:	{seismo,allegra}!umcp-cs!steve
USPS: Computer Science Dept., University of Maryland, College Park, MD 20742