phil@brahms.amd.com (Phil Ngai) (05/08/91)
I want to describe a feature that I feel would be very useful and see how others feel about it. Our company network is run by Unix bigots who will only allow TCP-IP protocols on the backbone, which of course, are lousy for PC Win3 users. What I would like to do is run our own private IPX network but still have the ability to access the workstation world for telnet, ftp, and NFS. The best system would seem to be to put two network interfaces in our Novell fileserver and let it bridge, route, and gateway services between our private IPX network and the corporate TCP-IP backbone. What's missing, as I understand the capabilities of Netware 386, is the ability for the Novell fileserver to act as an NFS *client* and mount a filesystem from a Unix host. There are many reasons why this is nice, including the fact that our Unix hosts have a nice backup system in place. Since we want the file server to isolate our private IPX network from the corporate backbone anyway, this wouldn't result in a wasteful doubling of filesystem traffic. How about it, Novell, would you consider putting this in? (what is a Unix bigot? Someone who responds by banning Novell if there is a single incident with it, but blames the users when there are multiple crashes involving PC-NFS.) -- The enemy of my enemy is my friend.
jal@acc.flint.umich.edu (John Lauro) (05/08/91)
In article <1991May7.170934.18198@amd.com> phil@brahms.amd.com (Phil Ngai) writes: >The best system would seem to be to put two network interfaces in our >Novell fileserver and let it bridge, route, and gateway services >between our private IPX network and the corporate TCP-IP backbone. NW 386 will not gateway TCP/IP services. However, it is capable of acting as a router. >What's missing, as I understand the capabilities of Netware 386, is the >ability for the Novell fileserver to act as an NFS *client* and mount a >filesystem from a Unix host. There are many reasons why this is nice, >including the fact that our Unix hosts have a nice backup system in >place. Since we want the file server to isolate our private IPX network >from the corporate backbone anyway, this wouldn't result in a wasteful >doubling of filesystem traffic. Will not work that way. NW 386 will only act as a server so that other machines can mount it. >How about it, Novell, would you consider putting this in? What you can do, is bind both IPX and TCP/IP to one board, and then bind just TCP/IP to the other. For telnet and ftp use one of the many commercial or freeware packages (including NCSA telnet, CUTCP, Lan Workplace for DOS/Windows (from Novell), FTP's, etc...) I stay away from NFS, but that would work too. (Using any existing NFS software you are currently using. Don't know if you can run NFS and Novell at the same time or not.)
Will@cup.portal.com (Will E Estes) (05/08/91)
<(what is a Unix bigot? Someone who responds by banning Novell if there
<is a single incident with it, but blames the users when there are
<multiple crashes involving PC-NFS.)
I'd say a UNIX bigot is someone who would rather spend $80,000 or more
for a Sun server that is out-performed by a less-than-$10,000 '486
machine running NW/386 and NFS.
Will Estes Internet: Will@cup.portal.com
UUCP: apple!cup.portal.com!Willghelmer@dsuvax.uucp (Guy Helmer) (05/09/91)
In <42116@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >I'd say a UNIX bigot is someone who would rather spend $80,000 or more >for a Sun server that is out-performed by a less-than-$10,000 '486 >machine running NW/386 and NFS. If you only want file services, NW/386 is great. I think you've understated the price, since NetWare 386 is now priced at $12,000 (+$3K to $8K for a 486, $2K to $3K for 16 to 32Mb memory, and $5K for disks) for 250 users, and Novell is going to get you again someday with expensive upgrades when the next big revision of NW/386 comes out or when you need to add services to complement the file services. (NetWare is going to be a big thorn in my side until a solid network name service exists for it, and when it becomes available you can bet it's gonna cost bucks). On the other hand, buy an $80K Sun server and you get an order of magnitude more functionality (compute services, database services (for some $$), backup capabilities, mail services, and so on), with the advantages of being able to upgrade a good share of the network services by just compiling new sources. You've got to match the server with the needs, and if you're a bigot for either solution, you're probably doing your users a disservice. >Will Estes Internet: Will@cup.portal.com > UUCP: apple!cup.portal.com!Will -- Guy Helmer, Dakota State University Computing Services helmer@sdnet.bitnet, dsuvax!ghelmer@wunoc.wustl.edu, wupost!dsuvax!ghelmer "I'm a cowboy, on a keyboard I ride..." -- with apologies to Bon Jovi
ken@racerx.UUCP (Ken Hardy) (05/09/91)
In article <1991May7.232850.7748@engin.umich.edu>, jal@acc.flint.umich.edu (John Lauro) writes: > I stay away from NFS, but that would work too. (Using any existing NFS software you > are currently using. Don't know if you can run NFS and Novell at the same time or not.) Does anyone know this ??? I might find out myself, though if it does'nt work, I won't necessarily know if it is impossible of if I did something wrong. What I want to try is to run an NFS server program (SOSS) on a '386 logged into our Novell file server so that my Suns can access the Novell server's disks by mounting them over NFS. Sounds spooky enough that I'll be inclined to believe anyone who gives me a halfway believable explanation of why it won't work. But I'm going to try it as soon as I can get SOSS up. I'll use two network cards if necessary. The crux of the matter, I believe, is how both SOSS and Novell get themselves into the DOS filesystem handlers and whether SOSS will serve drives being served to it by NetWare. I'm definitely not a guru in this area. The referenced article almost makes it sound (in a part not quoted here) as if NetWare can serve as an NFS server. Is this so? I am not one of those responsible for our NetWare server (being one of those Un*x bigots ;-> If NetWare can do this for me, it sounds like I'm wasting a lot of effort (though it still sounds fun to try). I guess I could go ask those in our organization who know NetWare ... BTW, our network has a lot of everything running on it ... Novell NetWare file servers, Suns talking NFS, IPX and NetBios datagrams broadcasting from data servers. No problems. -- Ken Hardy uunet!racerx!ken Bridge Information Systems racerx!ken@uunet.uu.net
rbraun@spdcc.COM (Rich Braun) (05/09/91)
In <42116@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >>I'd say a UNIX bigot is someone who would rather spend $80,000 or more >>for a Sun server that is out-performed by a less-than-$10,000 '486 >>machine running NW/386 and NFS. ghelmer@dsuvax.uucp (Guy Helmer) writes: >If you only want file services, NW/386 is great. I think you've understated >the price... I'll second that. NetWare is *overpriced*. We just spent $12.5K a pop for NetWare 3.11, *per server*. We have yet to pay the $5K a pop, *per server*, for NFS. So your comparison here is more like a $30,000 386 box vs. an $80,000 Sun box. Let's compare apples and apples, though, with a 386 NFS server: The Box $1,500 Memory, 8mb 1,000 Two 330M disks 2,500 & controller SCO Unix 600 SCO TCP/IP 450 SCO NFS 400 ------ $6,450 A wee bit less pricey than the $80,000 Sun system, and even a bit less pricey than the $17.5K Novell charges for 3.11 plus NFS. My TCP/IP subnet is likely to grow by leaps and bounds for every small increment our Novell network grows, if this price disparity continues. Call me a Unix bigot, if you must, but recall I'm also doing my part to help those of us who must continue dealing with DOS. -rich
andrew@jhereg.osa.com (Andrew C. Esh) (05/10/91)
In article <1991May8.184807.29998@dsuvax.uucp> ghelmer@dsuvax.uucp (Guy Helmer) writes: >In <42116@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: > >>I'd say a UNIX bigot is someone who would rather spend $80,000 or more >>for a Sun server that is out-performed by a less-than-$10,000 '486 >>machine running NW/386 and NFS. > > >You've got to match the server with the needs, and if you're a bigot >for either solution, you're probably doing your users a disservice. > >>Will Estes Internet: Will@cup.portal.com >> UUCP: apple!cup.portal.com!Will >-- >Guy Helmer, Dakota State University Computing Services >helmer@sdnet.bitnet, dsuvax!ghelmer@wunoc.wustl.edu, wupost!dsuvax!ghelmer >"I'm a cowboy, on a keyboard I ride..." > -- with apologies to Bon Jovi YES! I agree. Bashing any machine because of what it does to the network is merely pointing out the inadequacy of your network. A well built network should be able to handle the connection of any sort of node. Remember, we are talking about lans in this newsgroup. Let's find ways to make them work. Back in the original message there was a comment about the Unix bigots who won't let IPX run on the backbone. The idea of networking is to try to get different machines connected to one another. My question is: Why are these people in charge of the net? They obviously do not have the right attitude. Networking is different than computer use. The phone company doesn't let the end users tell them how to run their central switching offices. As networkers we should be trying to define more clearly what we do so it can be seen as a seperate job from System Administration, a job which requires a different mental attitude and a different set of skills. -- Andrew C. Esh andrew@osa.com Open Systems Architects, Inc. Mpls, MN 55416-1528 Punch down, turn around, do a little crimpin' (612) 525-0000 Punch down, turn around, plug it in and go ...
lws@comm.wang.com (Lyle Seaman) (05/11/91)
phil@brahms.amd.com (Phil Ngai) writes: >What's missing, as I understand the capabilities of Netware 386, is the >ability for the Novell fileserver to act as an NFS *client* and mount a >filesystem from a Unix host. There are many reasons why this is nice, >including the fact that our Unix hosts have a nice backup system in >place. Since we want the file server to isolate our private IPX network >from the corporate backbone anyway, this wouldn't result in a wasteful >doubling of filesystem traffic. >How about it, Novell, would you consider putting this in? Not very likely. I think Portable Netware or one of the other UNIX SMB servers is probably a better bet for you. -- Lyle 508 967 2322 lws@wang.com Wang Labs, Lowell, MA, USA
Jons@cup.portal.com (Jonathan S Spangler) (05/12/91)
>If you only want file services, NW/386 is great. I think you've understated >the price, since NetWare 386 is now priced at $12,000 (+$3K to $8K for a 486, >$2K to $3K for 16 to 32Mb memory, and $5K for disks) for 250 users, and Since we are talking about price, let's look at all the options here. Novell 386 is now referred to as NetWare v3.11. It is available in 3 levels, based on number of users: 20 user $3500 100-user $6500 250-user $12,500 Also, whoever said anything about 16-32 meg? The amount of RAM required is dependent on size of disk. Use this forumla to calculate RAM under NetWare v3.11: (.023 x M)/B + 4 = T Where M=total # of megabytes of storage B=block size T=Total RAM required. Let's assume 2 1.2 Gb disks. This is 2400 megs. (.023 x 2400) /8 + 4 = 11 megs RAM Also, how did you get $5K for disks? I can buy some pretty big drives for tha price -- probably 2 1.2Gb drives, giving me 2.4 Gb total drive space. Not bad for 5 grand... >Novell is going to get you again someday with expensive upgrades when >the next big revision of NW/386 comes out or when you need to add >services to complement the file services. (NetWare is going to be a big >thorn in my side until a solid network name service exists for it, >and when it becomes available you can bet it's gonna cost bucks). I agree with you on the upgrade pricing. Novell has a naming service now. >On the other hand, buy an $80K Sun server and you get an order of magnitude >more functionality (compute services, database services (for some $$), backup >capabilities, mail services, and so on), with the advantages of being >able to upgrade a good share of the network services by just compiling >new sources. So, let's see -- even if we take the high end of the NetWare server: 12K + 8K + 3K + 5K = 28K, right? Are you trying to say that it is justifiable to spend more than 2 1/2 times as much to get a Sun server? 50K difference in price...hmm that would buy ALOT of Novell upgrades, my friend... >You've got to match the server with the needs, and if you're a bigot >for either solution, you're probably doing your users a disservice. > >Guy Helmer, Dakota State University Computing Services >helmer@sdnet.bitnet, dsuvax!ghelmer@wunoc.wustl.edu, wupost!dsuvax!ghelmer >"I'm a cowboy, on a keyboard I ride..." > -- with apologies to Bon Jovi Jonathan Spangler jons@cup.portal.com
donp@na.excelan.com (don provan) (05/19/91)
The News Manager) Nntp-Posting-Host: na Reply-To: donp@novell.com (don provan) Organization: Novell, Inc., San Jose, California References: <1991May7.170934.18198@amd.com> <1991May10.211739.27830@comm.wang.com> Date: Tue, 14 May 1991 17:07:01 GMT In article <1991May10.211739.27830@comm.wang.com> lws@comm.wang.com (Lyle Seaman) writes: >phil@brahms.amd.com (Phil Ngai) writes: >>What's missing, as I understand the capabilities of Netware 386, is the >>ability for the Novell fileserver to act as an NFS *client* and mount a >>filesystem from a Unix host. There are many reasons why this is nice... > >>How about it, Novell, would you consider putting this in? > >Not very likely. I think Portable Netware or one of the other >UNIX SMB servers is probably a better bet for you. This is a funny thing to say. As Phil points out, there are many advantages to having NetWare 3.x function as an NFS client. It seems unlikely that Novell would ignore that market. don provan donp@novell.com
sob@tmc.edu (Stan Barber) (05/29/91)
In article <1991May10.142129.18462@jhereg.osa.com> andrew@jhereg.osa.com (Andrew C. Esh) writes: >Back in the original message there was a comment about the Unix bigots who >won't let IPX run on the backbone. The idea of networking is to try to get >different machines connected to one another. My question is: Why are these >people in charge of the net? They obviously do not have the right attitude. I have seen many, many problems with multiprotocol networks. If you have limited resources and can only do one protocol well because of the limited resources, what do you do? I say support TCP/IP. That will allow a much larger group of different machines to connect than anything else. Since those machines may or may not run Unix, I doubt any one can call the Unix bigotry. It may be TCP/IP bigotry, but that's a different than Unix bigotry. [Many people have a hard time seperating Unix and TCP/IP, but they really are not the same thing.:-)] With the availablity of tunneling on NW/386, why run IPX on the backbone anyway? Appletalk has been doing well for a long time using tunneling. Even DECnet can be encapusulated. This tells me that the Backbone operations folks and deal with TCP/IP connectivitity and those who need other protocols can just tunnel through. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
haas%basset.utah.edu@cs.utah.edu (Walt Haas) (05/29/91)
In article <5744@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >I have seen many, many problems with multiprotocol networks. If you have >limited resources and can only do one protocol well because of the limited >resources, what do you do? We have resources about as limited as anybody. It takes less of them to support five protocols on the wire than to support encapsulation. >With the availablity of tunneling on NW/386, why run IPX on the backbone >anyway? I would expect better performance in native mode, since there are that many fewer bytes of header to process. Perhaps more important there is less demand on our human resources since Novell RIP can do what it's designed to do, instead of forcing us to duplicate the same effort with static routes. >Appletalk has been doing well for a long time using tunneling. Could have fooled me- the problems with AppleTalk convinced us that was a bad approach. >Even DECnet can be encapusulated. As DECnet IV sinks slowly in the west this gets less interesting. DECnet V will be ISO, which should replace IP (they tell me)(I'm not holding my breath) -- Walt
phil@brahms.amd.com (Phil Ngai) (05/29/91)
sob@tmc.edu (Stan Barber) writes: >I have seen many, many problems with multiprotocol networks. If you have >limited resources and can only do one protocol well because of the limited >resources, what do you do? I say support TCP/IP. That will allow a much But we do have a multiprotocol network. We run TCP/IP and DECNET. My theory is that staff here feel VAXes and Suns are "real computers" and thus allowed to use their native protocols. But PCs are toys and anything invented in the PC world like IPX must be bad, let's ban it. Never mind the thousands of office workers who use PCs. Never mind its overwhelming popularity in the PC market. In fact, that's probably a strike against it. It must be too easy to use. We have a director responsible for networking PCs. Know what he uses? A SPARC. Why? Does he run SPICE or Logic simulation? No, he doesn't do any engineering. He runs email and word processing and stays completely out of touch with his users who need networked PCs. He doesn't use the applications his users use like Excel, Word, or Powerpoint. He runs a weird oddball package from a very small company that nobody has ever heard of. Our group tried it. We even bought workstations to run it on because he was supposed to be the expert and we trusted his recommendations. After considerable pain, we are throwing them out and buying Macintoshes. Now try to imagine his reputation in my department. After all, he has a real track record of success in the PC world, like picking 3Com for a Network Operating System vendor... -- The media is in the business of distorting people's perception of reality, by emphasising the out of the ordinary.
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (05/30/91)
In article <1991May28.230655.6545@hellgate.utah.edu>, haas%basset.utah.edu@cs.utah.edu (Walt Haas) writes: > > As DECnet IV sinks slowly in the west this gets less interesting. DECnet V > will be ISO, which should replace IP (they tell me)(I'm not holding my breath) For years it was said that Phase V would be ISO. Then there were rumors that Phase V is being delayed to add TCP/IP. You might conclude that IP is replacing OSI. Vernon Schryver, vjs@sgi.com.
sob@tmc.edu (Stan Barber) (06/01/91)
In article <1991May28.230655.6545@hellgate.utah.edu> haas%basset.utah.edu@cs.utah.edu (Walt Haas) writes: >We have resources about as limited as anybody. It takes less of them to >support five protocols on the wire than to support encapsulation. Is this just a guess, or do you really know? I really know. We tried to support multiple protocols in the beginning (back in 1984-86). It just didn't work for us. Perhaps you have such experiences to share? >I would expect better performance in native mode, since there are that many >fewer bytes of header to process. Perhaps more important there is less >demand on our human resources since Novell RIP can do what it's designed to >do, instead of forcing us to duplicate the same effort with static routes. I assume you mean Novell static routes and not IP static routes. IP routing protocols have had the ability to do things non-statically for a long time. I would think the Novell tunning software will gain such capabilities as it matures. >>Appletalk has been doing well for a long time using tunneling. >Could have fooled me- the problems with AppleTalk convinced us that was a >bad approach. Gee. There are an awful lot of Gator boxes and Fastpaths out there doing this. Perhaps you just had a bad initial experience. >>Even DECnet can be encapusulated. >As DECnet IV sinks slowly in the west this gets less interesting. DECnet V >will be ISO, which should replace IP (they tell me)(I'm not holding my breath) I seriously dount that DECNET Phase IV will sink very fast. I hope I am wrong, but I wouldn't bet against it. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (06/01/91)
In article <1991May28.230655.6545@hellgate.utah.edu> haas%basset.utah.edu@cs.utah.edu (Walt Haas) writes: >In article <5744@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >>I have seen many, many problems with multiprotocol networks. If you have >>limited resources and can only do one protocol well because of the limited >>resources, what do you do? >>Even DECnet can be encapusulated. >As DECnet IV sinks slowly in the west this gets less interesting. DECnet V >will be ISO, which should replace IP (they tell me)(I'm not holding my breath) Actually, DECnet V will support three protocol stacks: DECnet, ISO (GOSIP) TCP/IP, and Internet (ARPA) TCP/IP. A part of the delay in DECnet V can be attributed to betting on the wrong horse, ISO (GOSIP) TCP/IP. Internet (ARPA) TCP/IP did not disappear as expected from the Federal Government's GOSIP mandate. Novell has the same problem as Digital--a proprietary communications schema. Proprietary communications schemas are great for introducing small groups within an organization or small organizations to shared network resources. Most small groups eventually realize that they need to communicate with others within the organization or the world at large. Generally, it is cheaper to junk the proprietary communications schema and switch to something more universally acceptable and usable such as TCP/IP. Within the organization strange behaviours start to be exhibited by individuals closely aligned or committed to the proprietary schema. Software problems that have existed for ages start to be fixed. New software functionality is added. The common thread--utilization of unique features of the proprietary package. Both Digital and Novell will maintain their proprietary schemas. It makes strategic sense. If you get your foot in the door with the proprietary scheme, you become the first choice for providing a solution. You also see transition products being introduced. Novell's NetWare for VMS moves the file serving onto the VAX systems. Provides the capability to support a larger number of users and utilizes the VMS Backup and Restore capabilities to provide the capability to recover from catastrophic failures. Digital's PathWORKS (new name for PCSA, LANworks, etc.) now has the capability to co-exist with NetWare on a PC. With NetWare starting with F: or lastdrive +1 and PathWORKS starting with M:, we now have all sorts of places to store our goodies. We have VMS Mail and can send memos back and forth. If we have TWG's WIN/TCP or TGV's MultiNet we can send messages anywhere in the world, we can login to systems all over the world, and transfer files anywhere in the world. We can also have our PC clocks set to Co-ordinated Universal Time. In the future, DECnet V will provide the capabilities of WIN/TCP and MultiNet. Looking at the product brochure that came with NetWare 386 3.11, one sees that Novell is starting to introduce the NetWare equivalent of DECnet V. Having seen the effects of a "LAN meltdown", I am not terribly keen on having IPX packets let loose on the LAN backbone unless they are encapsulated. I do see an advantage to using NetWare for isolating "communities of interest". You might also refer to this as security through obfuscation. Using NetWare LANs for small groups or organizations whose work activities are closely related and then using a gateway to provide access to the general organization. This approach allows email to flow freely yet allows a modicum of control over access to sensitive data. I have rambled on. I probably could have said that Digital's DECnet and Novell's NetWare LANs have a role or niche to serve but TCP/IP whether ISO or Internet is what you want for general purpose connectivity. Merton Campbell Crockett
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (06/01/91)
In article <1991May28.230655.6545@hellgate.utah.edu> haas%basset.utah.edu@cs.utah.edu (Walt Haas) writes: >In article <5744@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >>I have seen many, many problems with multiprotocol networks. If you have >>limited resources and can only do one protocol well because of the limited >>resources, what do you do? >>Even DECnet can be encapusulated. >As DECnet IV sinks slowly in the west this gets less interesting. DECnet V >will be ISO, which should replace IP (they tell me)(I'm not holding my breath) Actually, DECnet V will support three protocol stacks: DECnet, ISO (GOSIP) TCP/IP, and Internet (ARPA) TCP/IP. A part of the delay in DECnet V can be attributed to betting on the wrong horse, ISO (GOSIP) TCP/IP. Internet (ARPA) TCP/IP did not disappear as expected from the Federal Government's GOSIP mandate. Novell has the same problem as Digital--a proprietary communications schema. Proprietary communications schemas are great for introducing small groups within an organization or small organizations to shared network resources. Most small groups eventually realize that they need to communicate with others within the organization or the world at large. Generally, it is cheaper to junk the proprietary communications schema and switch to something more universally acceptable and usable such as TCP/IP. Within the organization strange behaviours start to be exhibited by individuals closely aligned or committed to the proprietary schema. Software problems that have existed for ages start to be fixed. New software functionality is added. The common thread--utilization of unique features of the proprietary package. Both Digital and Novell will maintain their proprietary schemas. It makes strategic sense. If you get your foot in the door with the proprietary scheme, you become the first choice for providing a solution. You also see transition products being introduced. Novell's NetWare for VMS moves the file serving onto the VAX systems. Provides the capability to support a larger number of users and utilizes the VMS Backup and Restore capabilities to provide the capability to recover from catastrophic failures. Digital's PathWORKS (new name for PCSA, LANworks, etc.) now has the capability to co-exist with NetWare on a PC. With NetWare starting with F: or lastdrive +1 and PathWORKS starting with M:, we now have all sorts of places to store our goodies. We have VMS Mail and can send memos back and forth. If we have TWG's WIN/TCP or TGV's MultiNet we can send messages anywhere in the world, we can login to systems all over the world, and transfer files anywhere in the world. We can also have our PC clocks set to Co-ordinated Universal Time. In the future, DECnet V will provide the capabilities of WIN/TCP and MultiNet. Looking at the product brochure that came with NetWare 386 3.11, one sees that Novell is starting to introduce the NetWare equivalent of DECnet V. Having seen the effects of a "LAN meltdown", I am not terribly keen on having IPX packets let loose on the LAN backbone unless they are encapsulated. I do see an advantage to using NetWare for isolating "communities of interest". You might also refer to this as security through obfuscation. Using NetWare LANs for small groups or organizations whose work activities are closely related and then using a gateway to provide access to the general organization. This approach allows email to flow freely yet allows a modicum of control over access to sensitive data. I have rambled on. I probably could have said that Digital's DECnet and Novell's NetWare LANs have a role or niche to serve but TCP/IP whether ISO or Internet is what you want for general purpose connectivity. Merton Campbell Crockett
sob@tmc.edu (Stan Barber) (06/02/91)
In article <1991May29.162513.10529@amd.com> phil@brahms.amd.com (Phil Ngai) writes: >sob@tmc.edu (Stan Barber) writes: >But we do have a multiprotocol network. We run TCP/IP and DECNET. My >theory is that staff here feel VAXes and Suns are "real computers" and >thus allowed to use their native protocols. But PCs are toys and >anything invented in the PC world like IPX must be bad, let's ban it. >Never mind the thousands of office workers who use PCs. Never mind >its overwhelming popularity in the PC market. In fact, that's probably >a strike against it. It must be too easy to use. Comments I made related to the MANAGEMENT of the network. Let's assume you have a network the size of the internet running IPX. How would you propose to manage that? Now that Novell can use TCP/IP as the native network transport (instead of IPX), you can have the ease of use you want and I can have the network management capabilities I need. Sound like a win-win to me. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
phil@brahms.amd.com (Phil Ngai) (06/04/91)
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: >Having seen the effects of a "LAN meltdown", I am not terribly keen on having >IPX packets let loose on the LAN backbone unless they are encapsulated. We've seen meltdowns due to TCP/IP speaking nodes too. Either you've never seen them (hard to believe unless you are only working on a very small network), or you are trying to mislead by omission. -- The media is in the business of distorting people's perception of reality, by emphasising the out of the ordinary.
cjp310@coombs.anu.edu.au (Chris @ SSDA ...) (06/04/91)
phil@brahms.amd.com (Phil Ngai) writes: >mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) writes: >>Having seen the effects of a "LAN meltdown", I am not terribly keen on having ^^^^^^^^^^^^ >We've seen meltdowns due to TCP/IP speaking nodes too. Either you've ^^^^^^^^^ xcus my ignorance... But what exactly is a LAN meltdown ??? Thanks in advance. Chris -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Chris Patterson | Ph: +61 6 2492185 Social Science Data Archives | AARNet: Chris@coombs.anu.edu.au Australian National University | "I wonder what happens if I ..."
jqj@duff.uoregon.edu (JQ Johnson) (06/04/91)
haas%basset.utah.edu@cs.utah.edu (Walt Haas) writes: >We have resources about as limited as anybody. It takes less of them to >support five protocols on the wire than to support encapsulation. sob@tmc.edu (Stan Barber) writes: >Is this just a guess, or do you really know? I really know. We tried to >support multiple protocols in the beginning (back in 1984-86). It just >didn't work for us. I think I have experience doing it both ways. In general, I agree with Walt that in this era of multiprotocol routers it is much cheaper to route multiple protocols than to encapsulate them. However, your mileage may vary, particularly if you need to provide non-IP connectivity outside of a single campus network or homogeneous pool of routers. In general, I find that the cost of protocol routing is much lower than other costs associated with multiple protocols, notably the training my staff need to do a good job of understanding the interaction of the routers with host software. From that perspective, it doesn't matter whether you route or encapsulate. The important thing is to keep the number of protocols actually in use and supported down to a manageable level. -- JQ Johnson Director of Network Services Internet: jqj@oregon.uoregon.edu University of Oregon voice: (503) 346-1746 250E Computing Center BITNET: jqj@oregon Eugene, OR 97403-1212 fax: (503) 346-4397