-------------------------------------------------------------------- INTERNET.DOC -- 19980211 -- Email thread on Netware & The Road Ahead -------------------------------------------------------------------- Feel free to add or edit this document and then email it back to faq@jelyon.com Date: Mon, 4 Sep 1995 20:23:27 GMT From: NETNEWS@AMERICAN.EDU Subject: Re: Internet and Netware connectivity. >What I would like to do is to give access to Internet to about 10 users. >(I expect for that number to grow.) By access I meant e-mail, FTP, HTTP, >telnet. I would like to do this as seamlessly as possible. >I would like to know some alternatives to the current setup. There is >money to spend but not an unlimited amount. Lets aim for 3000$ as a >startup cost. I am currently testing an evaluation copy of Firefox's Novix for Internet on our 4.1 Server. So far it looks great. It was very simple to install, it allows you to keep the TCP/IP stack on the server, and provides security and firewall. You can get a Windows TCP/IP client package along with the NLMs or you can buy a "bare bones" NLM package and run your own Winsock compatiable software (as we are doing). A 10-user version of the Novix for Internet product which comes with NLMs and Client Applications runs for about 2,725. This will give you Email, FTP, Telnet, Mosaic, Gopher, and a Newsreader. Check out Firefox's web page at http://www.firefox.com/. They have a couple of articles from PC Week Magazine that give the pros/cons. It basically says that the product is a little more expensive than the others, but the security is great. Chris Joyce (cjoyce@vt.edu) --------- Date: Mon, 4 Sep 1995 07:21:00 GMT From: "Dan L. Parker" Subject: Re: Internet and Netware connectivity. >I have the interesting task of hooking up our company to the Internet. >The priority of these services is E-mail most importantly, the FTP and >Telnet, then HTTP. >I would like to know some alternatives to the current setup. There is money >to spend but not an unlimited amount. Lets aim for 3000$ as a startup cost. One way to accomplish this would be to install a communication server on your network. This would allow you to attach all of your modems to the comm server, and everyone on the network that you allow to could grab a modem and establish a dial-out or fax-out session. Multi-Tech, for example, provides software only or software/hardware solutions. They are located in Mounds View, MN, just outside of Minneapolis. Their number is 800-328-9717 or 612-785-3500. Their home page is http://www.multitech.com/ For software only, ask about the RNGCOM product, if you have an Ethernet segment, or the ASGTSR for token ring. This turns an existing workstation into a comm server. They also manufacture 8-port cards for increasing the number of ports. For hardware/software, they have the MiniArray, which supports up to 16 modems, or other async comm devices, such as ISDN or X.25. Any of these solutions would give you dial-in, dial-out, fax-in and fax-out over your network. They also provide a product called WINMCSI, which ships with the comm server solution, which would allow you to map and unmap workstation comm ports to the comm server. For example, you could tell WINCIM, the Compuserve Windows Information Manager, that there is a modem on COM 2. Then, use WINMCSI to map COM 2 on the workstation to a port on the comm server. Your workstation could then use a modem on the comm server to dial out to CompuServe and then to the Internet. If you decide to go with an Internet Service Provider, instead of CompuServe, you could handle Trumpet Winsock the same way. Multi-Tech also provides a 250-user license for their terminal emulation and fax software, which could run on each workstation for outbound datacom and fax sessions, or you can use whatever you are using now. All in all, it is a very complete package. ----------------------------- Date: Wed, 7 Feb 1996 01:00:42 -0500 From: John Carter Subject: bootp and Novell >I am using Hellsofts bootpd.nlm but ... > >If I edit the static list, I need to reload bootpd.nlm and it "forgets" >all the addresses that it had given out: two devices with same IP address. >The device that has just asked for an IP address, when rebooted gets the >same address, which is still in use ... > >The problem arises if I have to down the server and is most acute for >Macintosh users, the Mac holds on to it's IP address when given it unlike >for example Trumpet which asks each time it is used. > >What I need is an NLM that checks that an IP address is not already in use >before it gives it out: does anyone know of such an NLM or do I have to >set up a seperate machine. If you have a problem with the Static address, it is up to watch out when you switch ip numbers around. If you turned on the dynamic ip numbering, then yes that appears to be the one feature that they left out... No way around that with Hellsofts bootp until each user shuts off their macine. If you want to spends some big bucks, On Technology has a dhcp/bootp server. We used it for 3 months during beta testing, but when it was sold to On Tech, the price they were asking (1000.00 for 50 ip numbers, or 2000.00 for 250 numbers) was to high. It will do exactly what you want. It will give out Static or Dynamic IP numbers and remembers what dynamic numbers it sends out so when you reboot, it scans the numbers that it thinks it has given out and pings that person to see if they are still using it. It is a very reliable program and works nice with win 95. We only needed it for the 95 people and it was cheaper for us to setup an NT server for DHCP. ------------------------------ Date: Mon, 12 Feb 1996 17:40:01 -0600 From: Joe Doupnik Subject: Re: TCP with ODI >Where do I find A TCPODI protocol. > >I would like to connect a DOS PC to a TCP/IP Server using VLM's but I >have no info on TCPODI protocols. Where would I find something that Works. ------------- There isn't any such protocol as TCPODI. Let me explain briefly. ODI is a handler of packets, a multiplexer, to deal with board specifics by the MLID layer and framing details at the HSM (hardware specific module) layer, and handing incoming material to the proper application by the LSL. Ditto for outgoing material. These actions to not create nor change packets. VLMs are Novell-specific modules to deal with NetWare Core Protocol (NCP, have to have acronyms or folks don't take it seriously). At this time they use IPX for transportation, and IPX can also be carried in UPD/IP packets for NetWare/IP and IPTunneling. TCP/IP is a protocol stack, as is IPX and above. Both can use ODI if written properly. Some equivalents use NDIS board handlers and others can use Packet Drivers, etc. My UnixWare machine speaks IPX and TCP/IP; it uses variants of ODI but not the items you see in DOS clients nor NW servers. What you are looking for is a TCP/IP stack which knows how to talk to ODI handers, and that is independent of the IPX material associated with VLMs. Novell provides such material with the client shells. MS-DOS Kermit has its internal TCP/IP stack which also talks directly with ODI handlers. FTP Software Inc and Beame and Whiteside's TCP/IP stacks can talk to ODI too. ODI is very popular, for good technical reasons aside from sales and color of box. I recommend you look at Novell's client shells as a starter. Then also consider the programs mentioned above. You should have a good look at the list's FAQ for additional hints and advice. Joe D. ------------------------------ Date: Fri, 10 May 1996 18:24:56 EST From: Jayson Agagnier Subject: Re: free IP adresses ? The Internet Assigned Numbers Authority has the following addresses assigned for private Internet (or "Intranet" if you subscribe to "buzzword of the day" schemes) setups: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 173.31.255.255 192.168.0.0 - 192.168.255.255 I have included a small excerpt of the RFC below. 3. Private Address Space The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private networks: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255 We will refer to the first block as "24-bit block", the second as "20-bit block, and to the third as "16-bit" block. Note that the first block is nothing but a single class A network number, while the second block is a set of 16 contiguous class B network numbers, and third block is a set of 255 contiguous class C network numbers. An enterprise that decides to use IP addresses out of the address space defined in this document can do so without any coordination with IANA or an Internet registry. The address space can thus be used by many enterprises. Addresses within this private address space will only be unique within the enterprise. As before, any enterprise that needs globally unique address space is required to obtain such addresses from an Internet registry. An enterprise that requests IP addresses for its external connectivity will never be assigned addresses from the blocks defined above. In order to use private address space, an enterprise needs to determine which hosts do not need to have network layer connectivity outside the enterprise in the foreseeable future. Such hosts will be called private hosts, and will use the private address space defined above. Private hosts can communicate with all other hosts inside the enterprise, both public and private. However, they cannot have IP connectivity to any external host. While not having external network layer connectivity private hosts can still have access to external services via application layer relays. All other hosts will be called public and will use globally unique address space assigned by an Internet Registry. Public hosts can communicate with other hosts inside the enterprise both public and private and can have IP connectivity to external public hosts. Public hosts do not have connectivity to private hosts of other enterprises. Moving a host from private to public or vice versa involves a change of IP address. Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links. Routers in networks not using private address space, especially those of Internet service providers, are expected to be configured to reject (filter out) routing information about private networks. If such a router receives such information the rejection shall not be treated as a routing protocol error. Indirect references to such addresses should be contained within the enterprise. Prominent examples of such references are DNS Resource Records and other information referring to internal private addresses. In particular, Internet service providers should take measures to prevent such leakage. You view a copy of the RFC at the following locations: http://www.internic.net/rfc/rfc1597.txt http://www.ctrl-c.liu.se/ftp/doc/rfc/rfc1597.txt Both sites have a pretty complete listing of all the Request For Comments issued over the past couple of decades. Read RFC1000.txt for more information on RFC's in general. ------------------------------ Date: Mon, 10 Jun 1996 11:13:20 +0000 From: Bjarni µsmundsson Subject: Re: IWARE QUESTION Yes this is how IWare works, you don't have to add IP to the workstations. I have no idea if there is an demo version. I'm running 100 licence IWare on a NW4.10 server (2 licences). I intend to have users on 28 NW servers (primary schools) using the Internet via the IWare server and maybe some users from my network (100 users NW3.11). I'm just starting to use this and have installed it in about 10 locations. You can install the IWare client and you will then run IWare Connect but you can also just copy the Winsock.dll to the Windows/System directory and IWare takes care of the rest! I'm though having some problems on slower links. The network is connected via 64K and 14400 leased lines. Also I'm having some routing problems on some of the servers. ------------------------------ Date: Mon, 24 Jun 1996 08:19:57 +0200 From: Henno Keers Subject: Re: WAN >I am planning on connect my two networks in differant building to create >a WAN using 802.2. Both networks have one 4.1 server running on them. I would investigate in using one ethernet frame for all traffic, I don't know if TCP/IP comes into the picture, maybe ethernet_II might be a better solution. See the FAQ for some more details. >The networks will be connect so that uses can exchange Groupwise >E-mail, share a few files a week, and users at one site will access a >AS/400. The access to the AS/400 will be the main use. By means of what protocol is the AS/400 reachable, TCP/IP ? >What thinks do I need to contend with in creating a WAN? How do I limit >network traffic accross a WAN? You need: - To estimate the amount of traffic across the WAN link, which highly depend on the apps involved, large groupware apps arrent nice users of precious bandwith most of the time. From this estimate you should make a choice for a dedicated link or a non-fixed like 1 or mode ISDN connections. - To choose a brand of router, some points should lead you to the right choice, Initial price is not a good point of selection, better points are: - Good support - An established name, see the www sites of Cisco or BayNetworks. - Large base of users (so you can ask other users) - Lots and lots of options to tweek. This might be a bit of a pain since most people want simple controls, but with this equipement you want some more options and areas to tune and tweek. - Upgradable operating systems. - Establish a naming and numbering scheme, ever heard of the Utah standard ? - Make a choice in routing protocols: will it be RIP/SAP or NLSP for IPX ? Will it be RIP, BGP or OSPF for TCP/IP ? - After the link is established you should start filtering RIP/SAP traffic using access lists based on a SAP list (see the FAQ). >What do I need to think about with NDS? That you pass the two SAP numbers and that you have to tune its updates via the link. >How fast of a connection should I use? See above, investigate your users and your apps. >What do I need to have at both ends. A router and a connection to the WAN. ------------------------------ Date: Sun, 30 Jun 1996 13:54:35 -0600 From: Joe Doupnik Subject: Re: wan is saturated, is 802.2 better >>Our (10) 56k WAN links are saturated with ip and ipx traffic, >>we use ipx for pc's to access netware 3.12 servers on local segments >>and accross wan links, I am trying to think of ways to reduce wan >>traffic/improve efficiency, currently 802.3 is frame type used, is >>802.2 that much better? or should we use tcp/ip for everything and get >>rid of ipx traffic? > >On a WAN I would only use IP and PPP. >You can allways use IPX encapsulation and route it as IP. > >I'm not sure if 3.12 can talk OSPF instead of RIP. >Please examine if it would benefit you. > >As prefered frame I would use Ethernet_II. >It can handle both IP and IPX and makes IPX checksums possible. > >Using only tcp/ip can be prefered, depending on what applications you are >running (some of them need IPX/SPX/SAP). > >Is your network in good health? >Use the statistics in MONITOR and on the routers to determine >if there are any mishaps on the WAN. > >Arthur B. --------- Another tuppence worth. I have dealt with such WAN links and they were flooded with traffic of all kinds. Frame relay circuits for the most part here. What I recommended was first, put a NW server or other router between the locals and their WAN link to isolate the local-only traffic (of which there was a great deal). Do this on both ends of the link. Second, change from RIP/SAP to NLSP for IPX routing. It's designed for these situations, uses considerably less bandwidth than RIP/SAP, and it is smarter about slow links. Third, as Arthur says, use frame Ethernet_II for simplicity and most applicability. Please do follow Arthur's advice about turning on IPX checksums. Fourth, use Packet Burst and Long Internet Packet (LIP) support on both ends. That overcomes much of the progagation/queueing delay inherent in slow links Fifth, look at what people are moving across the wire and consider relocating/duplicating some apps/files for direct local access. Where we differ is on encapsulating anything. I recommend don't. IPX is very similar to UDP/IP traffic, and NetWare/IP uses just that for Novell work. Decoding/monitoring encapsulated traffic is a nightmare. Wrapping and unwrapping takes cpu cycles. Nothing is gained by encapsulation in this circumstance. Joe D. ------------------------------ Date: Wed, 28 Aug 1996 15:55:26 -0600 From: Joe Doupnik Subject: Re: RE[2]: trying to play net.police >>>We are trying to charge our students for Internet use and I would >>>like to ask you for ideas / products on how to do that. --------- Here's my thinking on the Internet charging matter. If the Internet lines are paid for already but full (normal) then that's the bottleneck and the natural throttle. Improvments generally come from a fund affecting everyone on site, since everyone turns out to be the customers involved. To impose charges to develop free capacity says charging folks to create empty capacity they can't use. If the lines are not yet full then what's the problem? If there is a charge per packet or byte or similar then there is a clear relationship between use and expense, and to a degree (no pun) one can try to charge back such expenses. Customers might well argue that less should be charged during sluggish times since their own time is also worth something. To create funds for just using equipment is another more general matter, rather separate from the Internet. When the equipment and personnel and software exist already under other funding arrangments, as we expect, then imposing a tax to use it is double taxation. To pick out some uses rather than others to be taxed is an assumption of authority not normally delegated to service units. An analogy might be interesting here. Motor vehicle traffic. This month I was in two distant countries: England and Egypt. Traffic in Cairo is anarchy personified. No one paid the least attention to the few traffic lights and stop signs in town (13M people) nor to idle traffic wardens on the streets. People drove as fast as they could go. If a path were too crowded at times then other paths or times were used or guessed at. Surprizingly it worked very well indeed, and the traffic flowed smoothly and fast. Folks used the same algorithms to make judgements and the sharing was distributed down to the individual level, Ethernet style. Hitting something was bad news because it caused delays and expense, so the general agreement was to not ding things and pedestrians (who must play by the rules too); Carrier Sense in action. Expenses were minimized. England is installing photo boxes on many traffic lights which take a picture and send you a traffic ticket in the mail for committing any number of infractions, all without human intervention. Traffic does move, at a moderate pace, polite Token Ring style. There is some empty space on the roads, which must be one of the design criteria. There is a higher chance of getting through a particular roadway at any time than in Cairo. Needless to say, this is very expensive but does not make traffic go any faster. But the system is "highly managed" and therefore "good." I don't think this was put to a vote. So, in one case folks used up all the resource and waited for more road-width to make things better. In the other queueing was spread all over by gentle coercion, at substantial financial cost, while minimal service was assured. Joe D. ------------------------------ Date: Fri, 15 Nov 1996 09:41:25 -0600 From: "Mike Avery" To: netw4-l@bgu.edu Subject: Ping of Death There seems to be a rather widespread, and serious, bug in a number of operating systems handling of received pings. For those of you supporting operating systems other than NetWare 4.1, you might want to look at http://www.sophist.demon.co.uk/ping/ --------- Date: Fri, 15 Nov 1996 22:35:55 -0500 From: "Charles R. Kelley" To: netw4-l@bgu.edu Subject: Re: Ping of Death For those of you using Linux boxes (hey, there might just be some out there besides me! :) I heard there was a patch just released to prevent the system from coming down when someone ping floods you (or whatever the correct term is). I beleive, but not positive it is kernel 2.0.25 or so that has this patch. --------- Date: 18 Nov 1996 From: Floyd Maxwell Subject: Re: Ping of Death To: Novell FAQ Executive Summary: The "bad" packets (can be any IP datagram) are those larger than 65,535 (2^^16-1). While anything above 65,535 is illegal, if larger packets can be sent then on reception and reassembly some operating systems will overflow. NW 3.11 with TCPIP.NLM v1.01 hangs the IP stack, NW 3.12 with TCPIP.NLM v2.02 rev 9 seems fine. NW 4.1 is fine. UnixWare is fine. Novell's C32DW and WfWg3.11 are fine (my own test). NT 3.51 and NT 4.0 will crash when _sending_ an oversized ping. --------- Date: Mon, 18 Nov 1996 08:49:55 -0600 From: "Fabio Esquivel" To: netw4-l@bgu.edu Subject: Re: RE>Ping of Death >It can also affect non-network-based OS's, such as 3.1, NT, 95 and >Mac 7.x. Prob others. I think it's effective on SOME OS for specific versions: I made tests in the following OS's: - Linux with kernel 1.3.100: Timeouts, but does not hang or crash - Win95 (with service pack #1 and kernel updated): Timeouts, but does not hang or crash - WinNT 3.51 (with service pack #3): Sometimes it gives timeouts, sometimes it answers correctly to the big ICMP ECHO (ping) packets but does not hang or crashes - AIX: Timeouts, but does not hang or crashes neither. - CISCO Router 2501: Timeouts also, but does not hang or crash; the routing tables do not get affected at all. ------------------------------ Date: Tue, 26 Nov 1996 08:44:28 -0800 From: Donovan Bray Subject: This is a forum for Netware Professionals! Attn: Gentlemen, whether or not we know everthing, (This list exists solely for the purpose of educating those who don't), I should expect you to act and communicate professionally. If I were a CEO of a company, to which you both were sitting accross a table discussing this, and treating each other the way you have on this list. I'D A FIRED BOTH OF YA! Now, shake hands, agree to disagree, and lets move on. If you believe its necessary to continue this discussion do it in private e-mail. It benefits nobody by adding this traffic to the list. This goes for all other would be flamers; If you wouldn't say it in front of your boss, or your client, then don't say it on this list. ------------------------------ Date: Mon, 17 Feb 1997 15:38:36 -0600 From: Joe Doupnik Subject: Re: New TCP/IP from Novell >I'm having some trouble getting the new TCP/IP from Novell contained >in TCPN03.EXE to cooperate with me. > >Check this.. I read in the install notes that you need to use the /C >option with the provided installr.bat if your on Netware 3.12, and not >using MPR. Thats me. So I do a > >installr /c f:\system > >and everything goes well, apparently.. > >When I try to load TCPIP.NLM, modules TCPSTNV.NLM and TCPCONV.NLM autoload, >and TCPCONV.NLM croaks with the following output: > >ADDCONV.NLM-1.0-3: Unable to read NETINFO.CFG. Further conversion aborted. >No existing configuration found. > >~~~~~~ >several lines about "Loader cannot find public symbol blah blah... > >~~~~~~ >Module TCPIP not loaded --------------- Well, as best that I can figure out, the people really meant this for NW 4.x and included NW 3.x as an afterthought. But it can operate on NW 3.12, as shown below in a cutout from console.log: Loading module PSERVER.NLM NetWare 386 Print Server (950523) PTF Version 3.76 May 30, 1995 Copyright 1995 Novell, Inc. All rights reserved. Auto-loading module NUT.NLM NetWare 386 Utility User Interface Version 1.13 December 20, 1990 Copyright 1990 Novell, Inc. All rights reserved. Loading module SNMP.NLM SNMP Agent Version 3.03 January 3, 1996 Copyright 1992-1996 Novell, Inc. All rights reserved. Loading module TCPIP.NLM Novell TCP/IP Module (IP0200.B02) Version 4.00 February 10, 1997 Copyright (C) 1991-1996 Novell, Inc. All Rights Reserved Auto-loading module TCPSTCNV.NLM MPR 3.0-1 Additional Conversion IP0200.B02 Version 4.00 February 5, 1997 Copyright 1996 Novell, Inc. All rights reserved. Auto-loading module CSLCNVRT.NLM CSL Conversion Version 1.00 January 4, 1996 (c) Copyright 1991-1996 Novell, Inc. All Rights Reserved. Auto-loading module BTRIEVE.NLM Btrieve NLM Version 6.10c November 19, 1993 Btrieve Record Manager (C) Copyright 1988-1993, Novell Inc. All Rights Reserved. Auto-loading module TCPCONV.NLM MPR 3.1 Conversion Utility IP0200.B02 Version 4.00 February 6, 1997 Copyright 1995-96 Novell, Inc. All rights reserved. ADDCONV.NLM-1.0-3: Unable to read NETINFO.CFG. FUrther conversion aborted. No exi sting configuration found. Auto-loading module CSLIND.NLM CSL Independence module (IP0200.B02) Version 4.00 February 5, 1997 Copyright (C) 1993-1996 Novell, Inc. All Rights Reserved Unable to find load file CSL.NLM TCPIP-4.0-42: Will NOT act as a router. TCPIP-4.0-27: RIP is disabled. TCPIP-4.0-6 6: Will use 129.123.1.254 as a default gateway. TCPIP-4.0-112: Bound to board 1 w ith IP address 129.123.1.44 and mask FF.FF.FF.0. IP LAN protocol bound to Novell NE3200 Loading module RDATE.NLM rdate Version 1.20 November 24, 1993 MurkWorks, Inc. (c) 1992,93 All Rights Reserved (315)265-4717 Search 2: [Server Path] SYS:SYSTEM\MERCURY\ RDATE:Will poll server every 60 minutes RDATE:Trying Host 129.123.1.9 RDATE Error:bind_t:Protocol not availale RDATE:Trying Host 129.123.1.2 RDATE Error:bind_t:Protocol not availale RDATE:Trying Host 129.123.1.7 RDATE Error:bind_t:Protocol not availale RDATE:All hosts failed, retrying in 60 minutes etc -------------- In this case I am running NFS for NW 3.12. We see a couple of things. First, the persistent sloppiness about formatting strings. Then there is the clobbering of RDATE. I cured the RDATE problem by telling it to use UDP via Rdate's /U command line switch. Novell seems intent upon blocking access to the TCP port. This machine, netlab2.usu.edu, does not have a hint of INETCFG material on it, hence no netinfo.cfg. My NW 4 machines do but not NW 3. We see one more thing after TCP loads, which is Btrieve is loaded to get all IP names on your segment for use by SNMP queries. Here that means the beast consumes about 500KB of server memory for a nearly worthless and extremely seldom used facility. I have complained about this. The idea of TCPN03.EXE is to have one TCP/IP stack for all conditions. An admirable goal considering the recent profileration of kinds for special situations. Finally, I had one INW 4.11 server crash in this TCPIP.NLM and I had to rapidly restore the earlier TCPIP.NLM. Another INW 4.11 server is ok but the traffic on it is minimal. So far netlab2 (NW 3.12) seems to be ok. Joe D. ------------------------------ Date: Tue, 8 Apr 1997 15:14:37 -0400 From: "Brien K. Meehan" Subject: Re: Transmitting and Receiving a packet >I want to know, in real time, how does an application working >on the network know the destination terminals socket. Is there a fixed >list of sockets that NOVELL has declared. A developers' list might be a more appropriate to discuss this. In the meantime, try ftp://ftp.novell.com/pub/updates/napi/prtdcsdk/dsoc1.exe. --------- Date: Tue, 8 Apr 1997 13:31:06 -0600 From: Joe Doupnik Subject: Re: Transmitting and Receiving a packet >I want to know, in real time, how does an application working >on the network know the destination terminals socket. Is there a fixed >list of sockets that NOVELL has declared. ----------- This is a common situation on networks. There are a limited number of "well known sockets" which every system is supposed to know. The reminder are open and should be registered before use. There is no directory service agent for sockets information. Novell itself is the registrar. Joe D. ------------------------------ Date: Mon, 28 Apr 1997 19:59:11 -0600 From: Joe Doupnik Subject: Re: Q about loading TCP/IP >I have a question about loading TCP/IP on NW 3.12 (fully patched). I >was reading the _TCP/IP Transport Supervisor's Guide_ (See - somebody >actually *DOES* read the Red Books before posting! :-)), and I'm >unclear about when to use some of the LOAD/BIND options. Astounding. I'm delighted to read that. >Specifics: My network is almost exactly like that of Case 1 in >Appendix D - Single Network with IPX and IP Nodes. I have a NW 3.12 >server, an IBM RS/6000 server (Unix host) and a Cabletron Annex >Terminal Server (another Unix host), all on a single Ethernet >network. > >Clients are almost all IBM PCClones, running Netx/VLMS with Novell's >TCP/IP stack (or Win95 w/ either MS Client or Client32). Currently, >the NW server is *NOT* loading IP. > >Q: the manual states that, in order to get IP support on this type of >NW network, I only need to LOAD support for Ethernet_II frames, LOAD >TCPIP, and BIND - using only the ADDR parameter. Fine; I understand >so far. > >But: why don't I need the GATEWAY and FORWARD parameters as well? >Are they needed only when crossing different topologies or segments >(I only have the one segment)? The manual states that if GATEWAY >is not specified, IP gathers all routing info from RIP. So, in my >secenario, it's not a requirement? (Does Unix automatically broadcast >RIP?) GATEWAY is the IP address of the machine on your IP wire which connects to IP places not on the local wire. If you have none then forget it. >FORWARD makes the NW server route IP packets, correct? Since I won't >have any other subnets, I won't need this, since I'm not routing >between networks. Also, in the FAQ, Joe D. advises to specify RIP=NO. >OK, but why? If you don't run IP traffic through the server from one board to another then don't forward (there isn't a place to forward to/from). RIP is evil. RIP listeners believe everything they hear via RIP and that includes bad info from mal-configured machines and outright lies. It is as if one believed everything one encountered on NEWS or TV talk shows. Turn it off and leave it off. To route IP use GATEWAY= which is a static route for all traffic not on the local wire, and you personally set it that way forever and ever. Ditto on your Unix boxes: don't load routed. Instead define a default route (equivalent to "gateway="). >BTW, the reason? I'm evaluating BackupExec, Enterprise Edition, which >will allow me to backup a Unix host thru a NW server - but only if IP >is loaded. I'm considering the Enterprise Edition, so I'd have a >backup method of backup (:-)), in case the tape drive on the RS/6000 >fails (as it has - twice! - in the last 3 months). BE is a good product; I use it here. But be careful about that Unix support (have it here). Right now it appears to be broken for unknown reasons, though it used to work. That is, the Unix side advertises as it should, but while the NetWare end hears the packets none is returned to form a connection. I suspect changes to TCP/IP on the NW servers. And the guys writing the Unix daemon have no clue about what is a Unix daemon so it is either loaded all the time by the system startup scripts or it traps you into keeping a login active while it is run manually. If Seagate is interested I can turn it into a nice real-daemon, and you may tell them that. Joe D. ------------------------------ Date: Wed, 15 Oct 1997 15:38:30 -0600 From: Joe Doupnik Subject: Re: TCPIP not routing >>I'm trying to setup TCPIP to be used with the GroupWise SMTP gateway >>(GW5). The SMTP gateway can not query my ISP's DNS. Upon using PING >>at the gateway(NetWare 4.11) server, I found I can only ping computers >>in my local LAN and the network attached to the other side of my router. >>I can't ping any IP address, hence the DNS, outside of that. > >Do you have static routing enabled in inetcfg? >Can you ping outside your router with another server? >If you can, check the inetcfgs of both servers and see what is different. >You will need to have static routing enabled for the SMTP anyway. -------- Some additional information. Prior to TCPN04.EXE Novell's TCP stack would lose its default IP route upon every reboot; not always but in many cases. The quick fix is to Load TCPCON, enter the routes section and add the default route manually (need enter only the gateway IP number). This too vanishes upon a reboot. The better fix is apply TCPN04a.EXE, use inetcfg to allow static routes, etc. That should be permanent. It may take some trying because inetcfg + tcpcon seems to be some kind of intelligence test. Please be aware that Novell's TCP/IP material wants to use only one subnet mask, applicable to all interfaces. In the meanwhile, please turn off IP RIP, and OSPF, and IPX NLSP. None does you any good, and they can make things worse. Use a static IP gateway address and plain old IPX RIP/SAP. Joe D. ------------------------------ Date: Mon, 3 Nov 1997 14:45:01 -0800 From: Brandon Fouts Subject: Video over Internet Video over the Internet First ask your self WHY. VCRs are cheap, video tape is cheap, VCR cameras are cheap, a properly edited video tape is much more informative than "live broadcasts" and has the advantage of rewind and replay. Conferences? Have you ever had a conference phone call with 4 or more people? Better yet 3 locations with 2 or more people at each location. Or try some "chat room" on the Internet. Not to say you won't find good reasons to try this technology, but consider the basics first -e.g. What is the problem and what are possible solutions. And try a pilot first to see if it works - you can go "rent video conference rooms" (often from the phone company) and try it on an actual event, not just a proof of concept - gee it works type of thing. Many times money spent on content has a much better pay-off than money spent on "delivery systems". I.E. Make a video, spend some money having it edited - re-shoot additional parts to improve on the original tapping etc... Telephone companies have been trying to give us Video over the Telephone network for about 30 years now. Someone may remember the actual details of these historical business failures. Try to learn from history, and don't just repeat it. Start with the WHY. ------------------------------ Date: Mon, 26 Jan 1998 15:16:05 -0700 From: Joe Doupnik Subject: Re: Wan links, packet loss >>>Turning off packetburst seems to be one solution, however, now you have >>>your WAN link tied up with lots of packet acknowledgements being sent. >>>If you have lots of ppl trying to use the WAN at once the ack's can eat >>>up a good partion of your T1. >>------ >> >> Nah. The link is Full Duplex: 1.544Mbps in each direction. ACKs >>are tinygrams, consuming very little bandwidth, and they are going in the >>direction opposite to bulk data. >> Joe D. > >Joe, I dont mean to nit-pic, but here I go :) > >You assume that there is no data on its way back to the server... which >may or may not be the case. Assume the WAN is congested in both >directions from activity (worst case) > >My understanding of not using PB over a WAN is that ACK's are tiny, but if >you have 20, 30, or however many ppl downloading and uploadind to a server >you will have lots of ACK's coming in both directions. If the T1 is >congested and the ACK's dont make it to their destionation in time packets >will be re-transmitted and that is just gonna make the congestion worse. > >Are you saying that its better to not use PB over a T1? > >Sean T. Finney ------- Not nits, but basic networking education at work here. A client either sends files or receive files, but not both at once. That's the starting point, and says a client (just one) is essentially a half duplex device like a human listening to a conversation. The returned ACKs are indeed tiny (say 64 bytes vs 1500 byte data packets, a 1:23 ratio). When we mix many clients together some send, some receive, most do neither at any given moment. Very often we find most receive, and that is frequently loading program bits and pieces. Thus traffic is again mostly unidirectional, from server to client. Even if the traffic were balanced ACKs packets are tiny in comparision to the packets carrying data. When the line becomes congested it is almost always because of data packets. The reason is the congestion is a fight for buffer space to hold a packet, more bytes needed for larger packets. The comms box would have to be pretty stupid to assign max length buffer slots to every packet. Timeouts result from either a lost ACK or EQUALLY from a lost data packet; the point being the transmitter gets no ACK, for whatever reason. The more unidirectional the data transfer the greater the chance that ACKs are going the other way on a nearly empty reverse channel. Even if ACKs compete with data going the same way the competition is 4% ACKs to 96% data so it is data that experiences most loss (an ACK will fit into a relay box buffer where a big data packet will not). Further, Packet Burst sends many many more data packets than ACKs. That's why it has the name packet burst. A conventional TCP transfer would have one ACK for every pair of data segments; pburst does not. This further unbalances the direction of data flow and reduces impact of ACKs. To make a case that ACKs clog the net you are going to have to work really hard to show that max 4% additional load in a statistically chaotic environment made a signficant difference. In essence all I'm doing is counting things here, for each direction. Joe D. ------------------------------ Date: Wed, 11 Feb 1998 14:15:00 -0000 From: Robin Bowes Subject: Re: Mail Server >1) Is a router necessary ? How can I connect a modem to the NW4.11 > file server? >2) How can you configure your NW4.11 file server if you have another > OS/2 Warp 4.0 mail server? I'm not sure what you are asking, but if you are looking for a cheap and convenient way to hook up a LAN to the Internet, check out http://www.mischler.com/iproute ------------------------------