JOHNSON@NUHUB.ACS.NORTHEASTERN.EDU ("I am only an egg.") (01/07/88)
Happy New Year and I have a question.
We have a back bone ethernet around the campus. Off of this is the
occasional diskless workstation farm. These are Sun systems. That's
the topology.
We also have a set of Class B internet addresses. The back bone
has been given a subset of these addresses and we want to use a
different subset for the off back bone diskless systems.
We have been waiting for Sun OS 3.4 to come so that we could use
subnets which seems to be the solution to separating things. We now
have 3.4 but can't get any of the diskless wonders to boot when we put
the class B addresses up. HOWEVER, booting seems to work just fine when
the diskless ethernet segments are given a class C address and the back
bone a class B address. We believe we are having a tough time making
Sun OS 3.4 work with subnets but aren't sure. It's hard to tell with
UNIX and we only have a moderate level of expertise here.
One more fly in the ointment is that we have a ComputerVision
system which is a Sun diskless wonder farm off a disk server which is
running Sun OS 3.2 and isn't likely to change any time soon.
ComputerVision is a little behind.
Question:
1) Has anybody made subnets or a similar configuration to the
above work with Sun OS 3.4? If so, HOW? (*help*)
or
2) If I bring this mess up with class B addresses on the back bone
and class C addresses on the diskless segments, will packets
with class C addresses ever escape on to the back bone? These
diskless systems are to be allowed to log in to other machines
which are on the back bone. The problem is that we are
scheduled to be connected to JVNCNet REAL soon and I don't want
addressing snafus because we can't get Sun OS to work or because
it doesn't work. Right now I very willing to believe that
problem is us and not Sun but one never knows.
* h e l p *
Chris Johnson
Northeastern University.ron@TOPAZ.RUTGERS.EDU (Ron Natalie) (01/08/88)
We have much the same situation and are also on JvNCnet. We just run 3.2 on everything and tell them that they are on a class B net and let the routers do ARP spoofing. We use CISCO, but most of the popular gateways support this mode of operation. The only area where any level of trickery arises is when a host has interfaces on two subnet cables. All of our Suns run 3.2. We decided to hold out until 4.0 rather than spending the semester debugging 3.4 which doesn't really offer any increased features (just bugs). -Ron
ron@MANTA.NOSC.MIL (Ron Broersma) (01/09/88)
I have had similar (painful) experiences with trying to get the subnet support on Sun OS 3.4 to work. I saw similar problems with the early attempts at getting subnets in 4.2 BSD and I assume that the Sun code has the same problems. I was able to fix the 4.2 problems because I had sources for it. I don't have Sun sources so I have had a hard time isolating the problem in Sun OS. Of course, all these problems were fixed in 4.3 which supports subnets very well in my experience. From what I can tell, it looks like the routing code is very braindamaged. On a host with multiple interfaces on the same Class B net (but all on different subnets) it cannot seem to figure out what's the right net interface to use when installing a route. It often gets the wrong one. I also found that I had to turn off routed because it was making important routes just disappear. At this point I've sort of given up on subnet support in Sun OS until my sources arrive (soon, I hope). Once I have sources I'm sure I'll be able to track down the problem and get a better understanding of what's going on. --Ron (ron@nosc.mil)
hedrick@athos.rutgers.edu (Charles Hedrick) (01/09/88)
Ron's commands might leave the impression that Rutgers does not support subnets on our Suns. Our copy of SunOS 3.2 does support subnets. (It is quite easy to do this, even without source.) While we use proxy ARP on our cisco gateways to do some of the subnet routing, where we choose to do so we do it by telling the hosts explicitly that it should treat all routes as local (route add 0.0.0.0 `hostname` 0). Of course this is not practical for hosts with interfaces on more than one Ethernet.
dpk@bway.UUCP (Doug Kingston) (01/09/88)
By default, Sun does not initialize the netmask with ifconfig e.g. ifconfig le0 `hostname` netmask 255.255.255.0 This needs to be done on the server only, since a 3.3 or 3.4 SunOS diskless node will make a ICMP netmask request. I am interested in knowing if this is the problem. -Doug-
slevy@UC.MSC.UMN.EDU (Stuart Levy) (01/11/88)
> By default, Sun does not initialize the netmask with ifconfig > e.g. ifconfig le0 `hostname` netmask 255.255.255.0 > > This needs to be done on the server only, since a 3.3 or 3.4 SunOS > diskless node will make a ICMP netmask request. Be aware that there may be a bootstrapping problem with this. The ICMP netmask request is broadcast, not sent only to the server, and SUNs (3.3 at least) take the first reply received. So if there are subnet-capable machines that haven't got the word yet, they might propagate wrong broadcast masks. If you wire the netmask into the server, and then either take other hosts down or feed them the right mask, just once, everything should work after that :->.