-------------------------------------------------------------- NOVTCPIP.DOC -- 19980206 -- Email thread on NetWare and TCP/IP -------------------------------------------------------------- Feel free to add or edit this document and then email it back to faq@jelyon.com Date: Fri, 20 Jun 1997 08:40:24 +0200 From: Hans Nellissen Subject: Re: tcpip address >I need a shareware programs thats displays the tcpip addresses >of all current users in netware environment. You want pdtstxxx.zip, where xxx is a version number. Its available at: ftp://msdos.ftp.sunet.se:pub/network/pdclkset ftp://ftp.lu.se:pub/network/pdclkset ftp://oak.oakland.edu:pub/simtelnet/msdos/pktdrvr ftp://ftp.funet.fi:pub/msdos/Simtel/msdos/pktdrvr and probably other Simtel mirror archives. ------------------------------ Date: Fri, 24 Oct 1997 15:02:44 -0600 From: Joe Doupnik Subject: Re: Packet Drivers for Client32? (trying to set up a DOS Web Browser) >We have a T1 connection to the Internet, unfortunately I have not been >able to find out how the network is configured on the district end; but I >am able to get Netscape working via Client32's TCPIP and WinSock. However, >since we only have 386/16's with 4mb of RAM, web pages take (literaly) >minutes to load. As I need as little overhead I can get, I have been >trying to get a DOS GUI web browser (called Arachne) to work. It needs >packet drivers to load, and I have tried several different ones, but to no >avail. What I am wondering is, is there a packet driver shim that loads on >top of Client32's TCPIP.NLM, and if there is, where do I get it? Here's >some configuration info: See below for the answer. And I've added a few comments on your configuration material. By the way, why not fix those poor machines with more memory so user's are not ground down waiting on swap files. >STARTNET.BAT >------------ >SET NWLANGUAGE=ENGLISH >ne2000 0x60 0x4 0x300 >pktmux 2 >pktdrv >C:\NOVELL\CLIENT32\NIOS.EXE Whoa. No. Only ONE board driver per board please. You have two: ne2000.com and the CNE2000.LAN items. Forget pktmux. Forget ne2000.com. >LOAD C:\NOVELL\CLIENT32\LSLC32.NLM >LOAD C:\NOVELL\CLIENT32\CMSM.NLM >LOAD C:\NOVELL\CLIENT32\ETHERTSM.NLM >LOAD C:\NOVELL\CLIENT32\CNE2000.LAN PORT=300 FRAME=ETHERNET_802.2 INT=3D4 >ISA MEM=D0000 >LOAD C:\NOVELL\CLIENT32\CNE2000.LAN PORT=300 FRAME=ETHERNET_II INT 4 ISA >MEM=D0000 >LOAD C:\NOVELL\CLIENT32\TCPIP.NLM Do NOT load TCPIP.NLM if you are using another TCP/IP stack. Only ONE (1, uno, singular) protocol stack of a given kind (say TCP/IP) over a board at one time. Anything else is *entirely* in your hands without assistance. >LOAD C:\NOVELL\CLIENT32\IPX.NLM >LOAD C:\NOVELL\CLIENT32\CLIENT32.NLM >pktdrv /f > > >NET.CFG >------- >NetWare DOS Requester > FIRST NETWORK DRIVE F > NETWARE PROTOCOL NDS BIND > PREFERED SERVER = "LIB_BH" > NAME CONTEXT = "LIB_BH" > >Protocol TCPIP > PATH TCP_CFG C:\NOVELL\CLIENT32\TCP > IP_ADDRESS 161.*.*.92 > IP_ROUTER 161.*.*.1 > IP_NETMASK 255.255.255.0 > >Protcol IPX > IPX SOCKETS 40 > > >RESOLVE.CFG >----------- >DOMAIN BVSD.K12.CO.US Oops. Make that K12.CO.US. The machine (not domain) is BVSD. >NAMESERVER 128.138.129.177 And you should have alternates too. >With this configuration, Arachne loads (it thinks a packet driver is >loaded) but refuses to open a web site, it says the DNS can't resolve the >name (even if you type in an IP address). Other TCP/IP packet driver >software refuses to even start up. --------- From: jrd@cc.usu.edu (Joe Doupnik) Newsgroups: comp.protocols.tcp-ip.ibmpc Subject: Re: odi pkt driver Date: 24 Oct 97 12:52:52 MDT >| I am trying to get novell client 32 and a odipkt shim to work >| together. here is a copy of my autoexec.bat icannot get it to work. >| the error message i get at the odipkt command line is cannot find link >| support layer. but there it is at lsl32.nlm am i using the wrong >| command line options? > >Client32 doesn't use ODI (that is, the 16-bit ODI that we all know and >love), so ODIPKT has nothing to talk to. Now of course, client32 likely But it does use ODI. And there is a protected mode to real mode shim provided by Novell with the suite, PDOSETH.COM for example. And that does work with ODIPKT. Docs on the 32 bit ODI material are on netlab2.usu.edu in directory ODI, for those who may be interested. With C32 for DOS/Win31 add these two lines after loading the main body: lsl.com pdoseth.com and add a PDOSETH driver entry to net.cfg. This should be documented with C32. Here is an example cutout from net.cfg: Link Driver pdoseth Frame Ethernet_II Protocol IPX 8137 Ethernet_II Protocol IP 0800 Ethernet_II Protocol ARP 0806 Ethernet_II Protocol RARP 8035 Ethernet_II Frame Ethernet_SNAP Frame Ethernet_802.3 Frame Ethernet_802.2 Joe D. ------------------------------ Date: Mon, 27 Oct 1997 09:09:20 -400 From: Jon Dustin Subject: Re: BINDing vs. INETCFG >I understand how the loading and binding of protocols to NICs in the >autoexec.ncf has been replaced by the INETCFG utility in Intranetware >(sp3a in this case) . . . HOWEVER when you BIND manually using >TCP/IP, it is possible (and necessary, in my case) to specify a >GATEWAY on the bind line... I can't find where to set this in the >INETCFG utility... You need to setup a DEFAULT ROUTE in INETCFG, pointing to your gateway address. This will perform the same task as the GATEWAY parameter did before. ------------------------------ Date: Fri, 31 Oct 1997 14:48:13 -0600 From: Joe Doupnik Subject: Re: TCP/IP question >I have been having problems recently with a machine. Its a 486DX >with 8 megs of memory. It runs Windows 3.1. It is attached to a >INW4.11 server. I loaded Client32 for DOS/WIN onto the machine. When >I installed Client32 I also chose to install TCP/IP and configured it >properly. We also use TrumpetWinSock. When you try to launch TCP >manager it gives the folowing message: > >Unable to laod TCP - No packet driver loaded: not found, or >winpkt/pktmux It's rather simple. You were trying to load two (2) TCP/IP stacks at the same time. No can do. Discard the Trumpet material and use Novell's supplied winsock material with its TCP/IP stack. Trumpet's stuff tries to own the lan adapter too, which is not permitted either. ------------------------------ Date: Wed, 5 Nov 1997 06:32:21 PST From: Kevin Miller Subject: Re: LDAP, novell, netscape >I run netscape suitespot on an NT machine. [suitespot] allows you to use >LDAP (Light Directory Access Protocol) to authenticate various ways. >I setup LDAP on my novell 4.11 server and I have been able to access >Novell's data from netscape communicator using a command like > >ldap://ipofnovell/o=org??sub > >all my objects will then be listed in my communicator window, >communicator's address book did not work so well. All that means that >LDAP is up and running on novell. > >Suitespot allows you to use LDAP authentication and it asks for the LDAP >server (novell's IP) and for the BASE DN . I presume the base DN >relates to the NDS tree but I'm not sure. For BASE DN I use >0=gonzaga (my organization) but when I open users and groups under >suitespot, suitespot says "No credentials obtained from administration >server (no match for user id) and the log for LDAP on novell says: > >conn=117 fd=9 connection from unknown (#suitespot's IP number) >conn=117 op=0 BIND dn="" method=128 > op=0 RESULT err=0 tag=97 nentries=0 > op=1 SRCH base="o=gonzga" scope=2 filter="(uid=admin)" > op=1 RESULT err=0 tag=101 nentries=0 > op=-1 fd=9 closed errno=0 I just went through this whole process, with the help of a few other admins on the net. Here are some tips to make Novell LDAP work with Suitespot: 1) Make sure the LDAP attribute "uid" is mapped to NDS attribute "CN". Unfortunately, with this mapping, you probably won't be able to setup a useful address book. If you want that, you'll have to setup a second LDAP server. 2) Make sure the message and screen log option called "Display configuration file processing" (or something similar) is checked. It seems that LDAP won't read the configuration unless these options are checked in the LDAP server object. 3) The base DN should be set to the NDS context were all searches should begin. I made the mistake of following the Base DN with a period. Don't do this, it's wrong. Once I got these items setup, it has worked very well. ------------------------------ Date: Thu, 15 Jan 1998 11:22:00 -0700 From: Joe Doupnik Subject: Re: TCPIP bandwidth allocation >> Forget it. There is no QOS for TCP/IP. There is no bandwidth >>reservation nor allocation, no priority. First see if you have a problem, >>identify what that problem may be, consider solutions. Most likely the >>problem will be insufficient capacity to your ISP, which is a matter >>between your site and them. Recall, traffic to points round the world >>varies extremely in throughput with bottlenecks being anywhere in >>between. > >A Cisco can however do priority-queueing where it forwards (say) Telnet >traffic before (say) web and FTP traffic. If you have an ATM >infrastructure that the IP is running over then you can possibly configure >guaranteed bandwidth between endpoints (eg using Newbridge Vivid >equipment). > >If you're running frame-relay and using a 3Com router you possibly can use >the firewall software, and switch the traffic into different FR channels >with different characteristics, according to the source IP address. You >might be able to do this with a Cisco, but I've not looked into it. > >I agree though, once the traffic hits an ISP all bets are off as regards >prioritising traffic. > >This is "Arcane and Obscure Features of Routers" time, and best talked >though with suppliers trying to sell you equipment. > >Richard Letts -------- Yes, but maybe I can clarify things a little at this point. The person wanted to give users different priorities, and that does not work over regular Ethernet. Routers may, or may not, be configured to pay more or less attention to certain ports and queues etc, but that's where the matter ends. Once traffic goes into the big world it competes packet by packet (ok, datagram by datagram) with everyone else, no priority, no reservation, etc. Dedicated point to point links can do what they please, but Ethernet has no reservation, no QOS, etc, and IP's facilities for it are 99.99999% of the time ignored by equipment and software alike. Those folks running ATM love to engage in discussions about priority, but I tend to think that's not a productive activity for most places (save the case of running local video conferencing material). In the end priorities are one-way tools: they ratchet to the highest level, despite attempts to keep a balance. Guarantees of bandwidth are similarly fruitless unless the entire link is under careful and thoughtful control. To repeat myself, the first step is to see if there is a real problem. Joe D. ------------------------------ Date: Wed, 28 Jan 1998 07:19:00 -0700 From: Hansang Bae Subject: Re: Re[3]: OSI model questions >How did you "learn"? Did you just read the book one time and it stuck? >If so I applaud you, and am very jealous of your photographic memory. >But for us mere mortals, we at some point had to "memorize" the material. I guess I was lucky. I had to take the net tech test after completing my CS requirements. Having taken a 4th year comp sci course in networking where we spend one fulll semester to the first 4 layers, it was kinda easy to take the test. Started out with rote memorization, then gradually understood it. Again, this is like MEMORIZING calculus equations, and not fully understanding it until you take Linear Algebra. Once you understand it, you can make up your own memorization tips like: Physical layer: Railroad tracks DataLink: Rail Yard worker linking the trains together. Only cares about putting the trains together, doesn't care what's in it. NETWORK: Yard conductor, tells the train where to go TRANSPORT: Controller in the office. Ensures the trains arrive on time and in the right order ------------------------------ Date: Wed, 28 Jan 1998 12:54:02 -0700 From: Joe Doupnik Subject: Re: Multicast definition >I'm looking for a definition of multicast. Lets see, a broadcast is from >one point say a server out to all other nodes, and a multicast would be... --------- What many/most system managers really need is a solid background in networking. The easiest way is to take a full length no-holds-barred networking series at a local university. But that's awkward for many folks who are earning honest livings. So below is a very short reading list which has been useful in my classes. None of these is pitched at the technician or operator level, but then degrees in rocket science are not required to understand networking. If the book spends much time on OSI layers then find another book. Andrew Tanenbaum, "Computer Networks". Read about the underlying concepts, free of particular protocols and industry jargon. It's deeper than it first appears; Andy is an excellent writer. Includes ATM details. Douglas Comer, "Internetworking with TCP/IP". A light weight survey of TCP/IP material. Easy to read, not worth much when details are required. This is part of a series of books, with volume 1 being of most interest. Richard Stevens, "TCP/IP Illustrated". Volume 1 is of most use. Hard nosed details with copious examples. Well written but presumes familiarity with the basics of TCP/IP material. This too is part of a series and related volumes (Unix in the related volumes). William Stallings, any of a large number but choose recent ones. William likes to talk on paper, and he does get across some points while overburdening one with standards-jargon. Quality has gradually improved over time. Radia Perlman, "Interconnections: Bridges and Routers". A readable book on how they work and the spanning tree algorithm she helped create. Underpinnings of NLSP but not obviously. Very informative for specialists. Kaufman, Perlman, Speciner, "Network Security, PRIVATE Communication in a PUBLIC world". A primer on network cryptographic technology, including NW 3/4 login details. If you talk with Radia personally be sure to have at least one of her books in your hands (a defensive measure). Ethernet specs are sold, not free, from the IEEE in the US. Many details are in the above references, but not all details. These are specs, not tutorials. TCP/IP suite specs are RFCs, free not sold, available round the world including from my machinery. nic.ddn.mil has a master collection. IPX specs are largely sold, but some are free, from Novell, Developer Relations. Novell's Technical Notes are now available free via Novell's web server and ought to be read. Your local Univ or commercial bookseller can look up ISBN numbers etc. Joe D. ------------------------------ Date: Wed, 4 Feb 1998 08:25:04 -0700 From: Joe Doupnik Subject: Re: Re[2]: IP subnetting >You can have a mask of 255.255.240.0 on a 192.168.x.x address, it is >known as super-netting. However, the important part is, Novell does >not support super-netting. You will have to change the network number, >or your mask. > >Erik M. Cummings ------ That's correct. You know, the curious thing is why Novell has not implemented supernetting. The reason it is curious is subnetting and super netting are precisely the same algorithm, to the very last bit. It says exclusive OR the source and destination IP addresses bit by bit, and then AND the result with the sub/supernet mask. If the result is zero the items are on the same IP network, else they are on different networks. Using the mask removes consideration of IP "Class" (the top few bits of the IP address). In a routing server the algorithm is applied to each interface in turn, and thus each interface can have its own mask, provided there is no confusion about overlapping network idents. Novell does not support a mask per interface, even though some utilities permit one to create them. Just why these simple things have not been implemented is a very good question. My guess is simple inertia. The solution for that is to make a large noise to Novell, and attach this message to the end so folks see how trivial the work is. Joe D. --------- Date: Thu, 5 Feb 1998 16:00:15 +0000 From: Guy Dawson Subject: Re: IP subnetting >Could someone who's "in the know" (most likely Joe D.) clarify the >terminology on the following? > - Subnetting > - Supernetting > - Netting (Jim Pretty might be joking, if so, it was a good one) For lots of detail on supernetting try RFC1383 http://www.roxen.com/rfc/rfc1338.html In short: subnetting - splitting an A,B or C network into multiple netowork by making the netmask longer (more than 8, more than 16 or more than 24 bits). supernetting - aggregrating two or more contigious A,B or C networks into one larger network by making the netmask shorter (less than 8, less than 16 or less than 24 bits). --------- Date: Thu, 5 Feb 1998 10:04:58 -0700 From: Joe Doupnik Subject: Re: Re[5]: IP subnetting >Could someone who's "in the know" (most likely Joe D.) clarify the >terminology on the following? ---------- What's left to explain? I did it yesterday in a few sentences. That is all there is to it, simplicity itself. Ok, words are not enough for some people so here's a little C (^ is xor, & is and, all on 4 byte unsigned qtys): if ((source->IP ^ destination->IP) & netmask) { /* non-zero, get here if not on same IP network */ blah; } else { /* zero, get here if on same IP network */ blah; } As to playing with words, don't. Choose whether or not to employ a network mask or rely upon the IP Class bits (and hence imply a mask which matches that Class). Joe D. --------- Date: Thu, 5 Feb 1998 17:22:46 -0700 From: Joe Doupnik Subject: Re: IP Subnetting >IP supernetting won't work on the VLM and Client32 for DOS - the current >IP stack from Novell does not support it. The reason it works with >Client32 for Windows 95 is that the IP stacks in Win95/NT are from >Microsoft and they support supernetting. > ------- And if one reads my description of netmasking one soon sees how silly it is to support sub and not super. In fact more code and cpu time is devoted to *not* supporting both than doing both. If one wonders why folks behave this way my best guess is they have never sat down and thought though the matter to fundamentals (expressed as one short line of C code in one of my messages the other day). We see the same "fog of war" effect in list traffic on the matter where buzz words and big concepts (aggregation of Class C) and so on are offered. Too many words, not enough reflection, and that's true for not just folks on this list. Use a mask or use Class bits is pretty much the whole story. So go embarass vendors on the issue. Joe D. --------- Date: Thu, 5 Feb 1998 12:48:40 -0500 From: "Erik M. Cummings" Subject: Re[6]: IP subnetting >Could someone who's "in the know" (most likely Joe D.) clarify the >terminology on the following? Actually, it is quite simple. network: default network mask. Using the entire range of your network (A, B, or C) as a single network. I.E> 205.206.201.0 is network and there are 255 (-2) possible ip addresses on this SINGLE physical network. subnetting: taking your network (A, B, or C) range and dividing it into smaller SUB-networks. I.E> Divide the 205.206.201.0 class C network with a mask of 255.255.255.240 results in the following networks: 205.206.201.0 - not used (older devices cannot use this) 205.206.201.16 - a single physical network with 16(-2) hosts. 205.206.201.32 - same as above .48 - etc .64 - etc .80 - etc .96 - etc .112 - etc .128 - etc .144 - etc .160 - etc .176 - etc .192 - etc .208 - etc .224 - etc .240 - not used (older devices again) As you can plainly see, the network number is now divided into 14 useable ranges. Each range can be used on a single physical network. But notice, you are restricted to 14 addresses on each network. - The 0 and 240 subnets are unuseable because on older stacks all 0's or all 1's was not allowed in the subnet number, just as it is not allowed in the network number. - All 0's in the host field is the network number itself! Therefore not useable to address a physical device. - All 1's in the host field is the broadcast address for that network, therefore not useable to address a device. If you wonder what all 1's or all 0's means, translate all of the above numbers into binary. supernetting: taking MULTIPLE smaller network (B or C) and creating 1 larger network out of them. I.E. Take the following class C networks: 205.206.16.0, 17.0 18.0 etc to 31.0 and make them one single network 205.206.16.0. This network appears the same as a class B which is subnetted (do the math). It is important to IP to understand that if you have the same network or subnetwork number that I have, you are on the same piece of wire (figuratively speaking of course). NETWARE SERVERS DO NOT SUPPORT SUPERNETTING. There is no question about this. There are no exceptions, there are no alternatives. Clients are another matter. But then who cares, because if I have a netware server with no supernetting support, on a supernetwork, it will hit the router incessantly and thus would be a very BAD idea. I.E. local destination traffic would go "TO" the router. Some routers will reject this traffic, some will forward it, it all depends. (Rejection is the usual case.) And if I have a client that has a supernet mask on a normal network, well, he won't go to his router when he needs to, and will have a difficult time getting to those other networks which he thinks are local but are really not. I have to say it is very important for people to specify WHAT device they are talking about. Also, if you do not have IP on your Netware server it obviously won't care whether you supernet, subnet, or don't, because it won't even touch the IP packets (figuratively speaking lest someone decide to correct me...). Someone "in the know" has spoken.... Erik M Cummings --------- Date: Thu, 5 Feb 1998 18:24:40 +0000 From: Richard Letts Subject: Re: Re[5]: IP subnetting >Could someone who's "in the know" (most likely Joe D.) clarify the >terminology on the following? Note: I'm not going to give numbers exactly when they're >1024. Once upon a time the ARPA allocated internet addersses in various classes: class A could have 260K hosts, class B 65,000 and class C could have 256 Most people looking at their site said "I'll have a class B please" (as we did) however 65,000 hosts on one network is rather a lot and so you need to chop up the address space by having a subnetmask, and subnetting the network. eg network class mask normal mask for the network 146.87.0.0 (Class B) 255.255.0.0 255.255.255.128 the class-B address space was quickly running out since it was 'just right'. The IETF engineers[1] looked at subnetting and said, hey, this means we don't need to assume the mask we can specify it in the routing updates and stick several contiguos address block together to make a more 'just right' block. eg network class mask 192.198.8 255.255.255.0 192.198.9 255.255.255.0 192.198.10 255.255.255.0 192.198.11 255.255.255.0 OR 192.198.8 255.255.252.0 This is known as super-netting: making use of the subnetmask to join contiguous blocks of address space together [aside: up above I wrote what the normal mask is for most of the networks here at the University of Salford. The network masks do not have to be the same across all of the subnetworks... and looking at a cisco router here I see: 146.87.0.0 is variably subnetted, 160 subnets, 5 masks with everything from 255.255.255.128 though to 255.255.248.0 only do this sort of thing if you understand routing protocols and are into serious pain when you buy a different manufacturer's router. ] I reccomend "Internetworking with TCP/IP" volume 1 by douglas comer [I wish I got commision for every time I recommend this book] or "Tcp/IP illustrated" volume 1 by stevens. The first book is more of a college text and I find more readable. the other is more of an engineering book and is more detailed and terse. I'd also reccomend people read RFC1918 on private address space and why using it is a VERY GOOD IDEA. --------- Date: Fri, 6 Feb 1998 14:01:21 -0700 From: Joe Doupnik Subject: Re: IP subnetting >1) Sub-netting is breaking down a given class scheme into smaller > networks. > >205.153.110.xxx against a mask of 255.255.255.240 gives you two smaller >sub nets. They are 205.153.110.64 and 205.153.110.128. >205.153.110.0 and 205.153.110.192 cant be used due to the broadcast >and network numbers. Inside .64 you can have valid ip addresses of >.65-->.126 .64 is considered the network number and .127 is a >broadcast number describing all addresses. > >2) Supernetting is just the opposite. > >It takes and combines multiple class C networks into a pseudo-class >B network. > >What actually happens is that the class C address are compared against >the mask. If the Match then they are all "let In" a Supernet mask against >the above mentioned of 255.255.254.0 would allow both the 205.153.110.0 >and 205.153.111.0 networks to be combined into a Supernet allowing >508 hosts on a given network. > >If the mask was 252 then a total of 4 class C networks would be combined. >A mask of 248 allows for 8 class C's to be combined and so on. >Hope this clears things up. > >larry ---------- Thanks for illustrating why folks are befuddled and confused, and outright scared, of sub/supernetting: too many buzz words by far. Real code is free of these embellishments and overtones; it is one line of C. Masks obviate Classes, all data are 32 bit unsigned quantities. I leave labels and such to philosophers. Again, my point is there is only one simple technical concept involved and it fits all occassions (including all router ports). I'm not picking on you Larry, but rather using your explanation as typical of discussions on technical material. We would all do better by getting to the essence of things once in awhile and set aside the standard story lines. Most often that essence turns out to be remarkably simple. Joe D. --------- Date: Fri, 6 Feb 1998 16:06:34 -0700 From: The Abundant One Subject: Re: IP Subnetting > Masks obviate Classes, all data are 32 bit unsigned quantities. This is the real trick here that people dont seem to catch right away. Every IP address eventually gets converted into a 32bit binary number that the computer sees/uses as its address. To really understand IP addresses, subnets, masks, etc brush up on your decimal <--> binary conversions and convert whatever IP address and mask you want to its binary equivalent and examine. Things start making alot more sense then. Example: 192.168.50.150 with a subnet mask of 255.255.255.240 Convert to IP 192 . 168 . 50 . 150 Binary 11000000.10101000.00110010.10010110 Mask 255 . 255 . 255 . 192 11111111.11111111.11111111.11110000 Combine IP 11000000.10101000.00110010.10010110 Mask 11111111.11111111.11111111.11110000 Now its really clear whitch bits in the IP address make the 'network' portion of the address make up the 'node' portion (the network bits are masked with 1's and the node bits are masked with 0's) ------------------------------ Date: Tue, 3 Feb 1998 17:06:10 -0700 From: Joe Doupnik Subject: Re: IPX to IPX through Internet Wan? >I come again with a nasty question, please have a look at the following >diagram: > >+-- WIN95 --+ +-- INW 411 --+ >| LAN A | | TCP/IP/DNS | +---+ +--------+ >| +----+DHCP/NIAS 4.1+---//---|ISP|---|INTERNET|---+ >| IP GATEWAY| | Border Mgr | +---+ +--------+ | >+--- IPX ---+ +--- IPX -----+ | > | >+------------------------------------------------------------+ >| >| +-- INW 411 --+ +-- WIN95 --+ >| +--------+ +---+ | TCP/IP/DNS | | LAN B | >+---|INTERNET|---|ISP|---//---+DHCP/NIAS 4.1+----| + > +--------+ +---+ | Border Mgr | | IP GATEWAY| > +--- IPX -----+ +--- IPX ---+ > > >We'd like to connect LAN A to LAN B and create a virtual private network >(VPN) using Border Manager but there are things still unclear to me (as >I hardly can't test this configuration in a real extent): This is a classical situation requiring IP tunneling. That is, the Internet carries IP traffic, not IPX, and thus IPX datagrams need to be placed as data within UDP or TCP for IP datagrams. Full NW/IP can do the job without an extra level of headers by using IP directly (no IPX). Basically one does not want to do this. First, the Internet is of extremely variable capacity, normally low, and losses can be high during busy times. Second, IPTUNNEL uses UDP/IP where there is neither an acknowledgment nor any notion of flow control (congestion avoidance which is REQUIRED for stable use of the Internet). Experience has shown throughput is truely rotten on all but local links. NW/IP (true) uses both UDP/IP and TCP/IP, depending on whether the material is tiny or lengthy, respectively, and that is a step in the right direction. Third, IPX uses lots of RIP/SAP traffic, and unless very heavily filtered, that is total garbage to dump on the Internet. The Internet is not a private dumping ground, though the spam idiots seem to think it is, and we should not dream of abusing it that way. For dependability and consideration for all other users of the Internet please use a leased line. Frame Relay is not useful in many cases because throughput is often terrible and consequently the cost is lower. Get a leased line, or if necessary a Frame Relay line, split the costs amongst users by formal agreement, forget counting details. >- Which services are transported through the VPN ? Only TCP/IP services >or can I run IPX services as well: NWADMIN, file and print services ... >from a station on LAN A can I map a drive of a server located on LAN B ? See tunneling above. >- Currently, LAN A and LAN B are on different NDS trees: do they need to >be on the same tree ? The answer to this is the same as if there were no long distance involved. >- More specifically about Border Manager: is there any accounting >function of bandwidth utilization per user so we could calculate the >cost of the Internet connection per department ? No. And that's not the way to chargeback. Nickel and dime charging of this kind eats the metering machine alive and generates huge reports, none of which activity we would like to be resident on our servers. Further, the line is always on, which means you have to apporition costs for the idle times too. And when a difficult person challenges the proposition they may well claim you are charging for the few microseconds between packets. The notion is just not workable. Divide the costs by political agreement. Joe D. ------------------------------