Return to BSD News archive
Xref: sserve comp.os.linux.development:22978 comp.os.386bsd.development:3102 Newsgroups: comp.os.linux.development,comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!pipex!uunet!easix!news.uni-stuttgart.de!news.belwue.de!news.uni-ulm.de!rz.uni-karlsruhe.de!stepsun.uni-kl.de!sun.rhrk.uni-kl.de!weber From: weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT]) Subject: Re: SAMBA and NETWARE mounting Message-ID: <1995Jan28.205413.3955@rhrk.uni-kl.de> Organization: University of Kaiserslautern, Germany References: <D2KG6E.CMp@park.uvsc.edu> <D2LH48.3IF@pe1chl.ampr.org> <D2qACr.A46@park.uvsc.edu> <D2s16r.428@pe1chl.ampr.org> <D2vrE0.D8M@park.uvsc.edu> <D2x440.1J1@pe1chl.ampr.org> <D2z554.K4F@park.uvsc.edu> <1995Jan26.162507.26091@rhrk.uni-kl.de> <D32vvM.5ro@park.uvsc.edu> Date: Sat, 28 Jan 1995 20:54:13 GMT Lines: 262 Hello, Terry Lambert <terry@cs.weber.edu> writes: >weber@rhrk.uni-kl.de (Christoph Weber-Fahr [KIT]) wrote: >] >OK, neutrally speaking, what would you point to as the main >] >advantage of IPX? >] >] He already said so. Larger address space. I would like to add: >] Automatic configuration of network and station adresses at ordinary >] (non routing) systems. >Excuse me, but address space is only an applicable argument if you >have that many hosts on a single network. No, it is not. It also means that you don't have all those problems associated with IP subnetting. Even if shortage of host numbers is not an issue, shortage of (sub-)nets frequently is. IP subnets at this University are a (wisely adminitrated) rare resource. Getting another IPX network number is utterly trivial. >Autoconfiguration is a function of your client software if the >servers on your net are properly configured. Except that there is a number of methods to choose from, that client software typically supports between zero and all of them, except the one you need, and that you have to carefully configure additional servers for that. >And we all know that there is no such thing as an IPX Internet so >far, and God willing, there never will be. Although I share your hope, one might add that since most Universtities on the net have implemented the Utah naming and numbering scheme, this is well technically possible (and, at least in Utah, even reality). [...] >[ ... NetWare/IP as an argument that NCP does not imply IPX ... ] >] You simply won't get what you describe here. Netware/IP effectively >] doubles the system cost, simply for using NCP on top of IP instead of IPX. >Of course it does. Novell has a vested interest called their >installed user base, which encourages them to make IPX cheaper >than IP. This is an Euphemism... you buy the normal IPX based product, and then you pay about the same for a box that makes the thing use IP instead of IPX. There are very few situations where this additional cost can be justified. [... specualtions about Novells Motives deleted ... ] >]] >You want a technical attack on IPX? OK, how about the lack of >] >packet checksums? >] >] As long as you have them on the media level, one might argue that you >] don't need them at the protocol level. Moreover, AFAIK they _are_ in the >] IPX spec anyway, but not implemented on the usual media. >PPP. Don't press me on PPP, but I seem to remeber that there was a technically sound solution for IPX on PPP... >SLIP. Serial Line IP ... there is no SLIPX :-) >Async bridging. >Lots of media doesn't support hardware correction. For instance, >bridging to Frame Relay from a Novell supplied MPR using an NE3200 >card. Here you might have a point. I simply have no Idea. >] > How about the misimplementation of the 802.3 >] >protocol encapsulation header? >] >] You refer to a specific IPX implementation, which is obsolete for a number of >] years now (though still widely used) ? >I refer to the only 802.3 IPX implementation. Huh ? Last Time I Checked there are three of them to chose from. Plus a correct Ethernet II framing mode. The one you refer to predates the 802.3 standard a little bit, and its use is discouraged by Novell for years now. >And the reason it is >widely used is that it is the default configuration for Novell >supplied client software. May I respectfully suggest that your Information is outdated ? About one or two years or so ago, Novell dared to change the default value of all the client software they deliver. We still have frequent complains of users in the Novell newsgroups about 'my PC doesn't find its Server' because of that. >] >] Also, there is a MODEM pool which is to be accessed from the PCs, and >] >] of course there are some printers. >] >] >Much of the NetWare print model is a joke. The lpr protocol at >] >least does not use timeouts to indicate end-of-job! >] >] Netware doesn't either, but has a clear well defined print job concept. >] The mere fact that utilities that try to emulate a locally attached printer port >] must use timeouts, simply because braindead DOS software insists in using >] these ports doesn't mean there aren't more clean ways to send data to a Netware >] printing queue. >This is BS. This is as wrong as the argument that because DOS >does not support a "search end" mechanism that the file searches >should be pushed into the network API's. >And it's plain false. NetWare does NOT support end of job >notification in rprinter protocol. Internally, it uses timeouts, >with a certain amount of line silence indicating end of job. You >are confusing the print redirection in DOS machines (the CAPTURE >command *does* support timeouts in notification to the enqueuing >mechanism) with the rprinter IPC mechanism used between the program >that dequeues the job from the print queue and the program that >shoves it out a printer somewhere (the second part being the piece >that uses the timeouts to indicate end of job). Funny that you mention it. I've seen it from an Application/Adminstration view. The internals of the rprinter protocol didn't bother me until now. IMO the whole rprinter stuff is a hack to make DOS stations work as a print server in background. (And the only reliable implementations of this hack comes, as usual, not from Novell but from third parties). The 'real' Netware Print Model is a Print Server serving remote and local print queues. And there you have a wonderful Job Concept. But, admittedly, this is a philosophical question and you definitely have a point here, as, for various reasons, the rprinter protocol is widely used. >] >How about NCP clients over an IP transport to NetWare for UNIX? >] >] >That buys me both the ability to throw away all of the IPX issues >] >and concentrate on a single network transport protocol framework. >] >] This buys you in the first place a nice red box >] [...] and nothing more. It buys you, >] at best, about 20k of free memory in every PC using it, provided you have >] already used Lan Workplace or PC/TCP before. Else ? Well, in small and >] medium sized installation using and routing IPX is as painless as it could >] be. In large installations, you probably already have equipmant that can >] handle IPX as well as IP, so why bother ? [...] >In small to medium installations, the routing of IPX may not be a >real issue (remember that we started out talking about internet >systems!), but price-point becomes one. As a small business, I am >much better served using the default peer networking that comes >on my machine that comes installed with a Microsoft OS, which will >be Windows 95 in the very near future. And which protocol do they use ? IP ? Well, then you're back at routing like mad. NETBEUI ?? Kiss your routers goodbuy, you're back at bridging. The small business may or may not be better off with a peer-to-peer networking product (which is not really the topic here), but it will most definitely use either IPX or IP once there are more than a hand full of PCs. And therefore my argument about the disadvantages of IP in this context holds. >If administration is an issue (as you imply in the next paragraph), >I am much better served going with Lantastic than either Microsoft >OR Novell. I guess at this point we simply must agree to disagree. I do not believe that. And I doubt many others will believe. >] On the downside, you are now the proud owner of a number of hassles you >] possibly didn't have before - you suddenly start administrating IP numbers >] for every f* PC you have on the net, you have to worry about subnet numbers, >] correct (default) router entries, nameserver configurations ect etc. >You must be referring to an IP stack that doesn't support DHCP. Talk >about legacy systems! Or BOOTP. OR RARP. Or whatever. Which IP stack do you think I refer to ? Better yet, which IP stack would you recommend for that ? >Default routing in a large network is already a problem with IPX, >which requires SAP restriction to make it work, which requires >routers with more knowledge of protocol decoding than they should >be required to have. Here we are at the point where you are 100% correct. SAP is a mess that doesn't scale well (or better, it doesn't scale at all), and the major improvement in Netware/IP, compared to their previous IPX tunneling, is putting the whole SAP information stuff into the DNS. OTOH DNS has other problems, or better, points where it could be improved. I need 10 seconds to get an IPX system fully operational here on the net, while an IP System may need several days (calling/e-mailing the guy who administrates the DNS here, filling out a form for his database, waiting until he gets the entry done, etc..). >] >Admittedly the self-tunneled IPX in the NetWare/IP product is a >] >kludge, but it's less of a kludge than replacing all of the Cisco >] >and Kalpana boxes on the planet with Novell Servers running the >] >multiprotocol router NLM. >] >] Why the hell do you want to replace CISCo routers ? They route IPX quite >] well. (I associate Kalpana primarily with Ethernet switches, so I don't know >] where the problem should be in this case). [You seem to invert the question to 'why should I not use IPX with CISCOs...] I know that SAP is a problem, but OTOH most of them have features to reduce the problem down to a manageable level. It works, even at a lot of Universities. [..because it didn't work in some cases,..] >Because [...] >most people don't know >how to set up a heirarchical map of NetWare servers to optimally >reduce the SAP traffic to manageable levels. Which also can be said for IP. Lacking skills of network administrators can do wonders anywhere. >As was demonstrated when USL was brought on the Novell corporate >network without initial protection from SAP. Adding the SAP >traffic for 1200 machines which bitch about who they are every 55 >seconds is a quick way to drop a net to its knees. But of course there are never IP/ICMP/WHAEVER broacast storms. Badly designed Networks can fail regardless of the protocol. And as long as IPX is nearly exclusively used by systems announcing themselves or looking for others by SAP broadcasts, you will have to take technical measures to deal with that. But these measures are seriously less expensive than converting to netware IP, not counted the additional administrative costs IP might bring you in a number of cases. [... NFS vs NCP Performance discussion deleted ...] You have a point here, although it isn't as bad as it used to be. The most recent CERT announcement OTOH again emphasizes the security concerns that have been said here in favour of NCP. >The Novell dinosaur needs to change with the times. Here I agree with you. But, to come to a conclusion, we talked about IPX vs. IP. In my opinion, both protocols have their weak points. And choosing IPX over IP may in a number of installations, even new ones, be a good choice, as ist IP in others. Both protocols are, by historical as well as economic reasons associated to technical solutions of which some are inferior or even sadly lacking. And it's nice to have several evils to choose from :-) Regards Christoph Weber-Fahr -- Christoph Weber-Fahr | E-Mail: weber@rhrk.uni-kl.de Universitaet Kaiserslautern, KIT | S-Mail: Postfach 3049 Tel. 0631/205-3391 | D-67653 Kaiserslautern -------------------------- My personal opinion only ---------------------