From: jrd@cc.usu.edu
Newsgroups: comp.sys.novell
Subject: Re: IP tunneling ...
Date: 5 Sep 92 23:07:04 MDT
Organization: Utah State University

In article <1992Sep6.000556.4309@usl.edu>, jmfres11@ucs.usl.edu (Karthikeyan Gurnswamy) writes:
> Hi ! 
> I am looking for information on IP tunneling software to connect distant
> Netware servers and clients with TCP/IP. Can someone give me info. if
> it is already done anywhere ? 
> 
> Would be really great if Keith, Don Provan, Joe D and Erick Engleke can 
> enlighten on this topic.
> 
> We are in the process of developing one and we would like to know if 
> it is done elsewhere. 
> 
> Thanks,
> 
> Karthik
> /----------------------------------------\--------------------------\
> | Karthikeyan Guruswamy                  | We survived hurricane    |
> | Graduate Student, Computer Science     |                          |
> | Center for Advanced Computer Studies   | ANDREW ...               | 
> | Univ. of SouthWestern Louisiana        |                          |
> | Lafayette, LA 70501                    |                          |
> | Email: jmfres11@ucs.usl.edu            |                          |
---------------
	As has been mentioned NW 3.11 comes with an IPTUNNEL NLM, and it
works. We put this through its paces here in the State of Utah to join
campuses over the WestNet backbone (IP, part of the NFS part of the Internet).
It worked, but it was not at all what we really wanted to achieve. IP tunneling
relays EVERYTHING from one server to the other server far away, and that is
not a swift idea for either sites nor for Internet lines.
	Our current solution is much much better. We use cisco Inc routers
to get off campus. They can proxy for the NW network at another site and
relay traffic to/from that site. By proxy I mean that the cisco at one site
gathers all the NW advertizing pkts into a table and then at an adjustable
time (several minutes in our case) it tells the other cisco about things.
Meanwhile each cisco emits local advertizements on the normal NetWare time 
intervals based on the table information of the other site. Thus, one copy of
information is sent (vs all servers telling all servers about all servers and 
all networks it has ever heard of; an N by N problem).
	Further, the ciscos are set to filter out all but selected adverts,
such as no printer blurbs, and all but selected servers (so many can hide
peacefully). Ciscos work this magic "at wire speeds."
	The transfer speed is at least double that of tunneling. Once set up 
the users see a very natural extension of SLIST etc. Transfers are going
to be slower by the propagation delay to get ACKs, and Packet Burst mode
is ideal for this situation. Over an 80 mile distance file transfers run
about 60++ KB/sec with cisco routing, and about 35KB/sec with tunneling,
all on a very high speed Internet link (T1 at the time of these measurements, 
now 48 Mbits/sec T3).
	Just think about the advertizement issue for a moment. Each NW file
server sends a routing table of names each minute as a cascade of packets.
It also sends a routing table of network numbers each minute as a cascade.
Each table includes information learned from incoming tables. So N servers
are sending 2*N tables every minute as broadcasts, and the tables grow as
more objects are known. The traffic (bytes) on this grows geometrically (N**2).
Pretty soon even News traffic has competition. Thus tunneling is useful in
smaller configurations and gets bogged down when large sites are joined.
	There is another issue about joining sites, which is guaranteeing
unique names and numbers for objects. This problem is not small, nor cheap,
unless one does something very simple. After discussion with many people
we selected using the Internet as our workhorse for doing the unique naming
and numbering. We name each Novell object by its Internet name, but with
dashes in place of dots (NW does not like dotted names) and the components
placed in reverse order so sorting programs do the humanly natural thing.
My well known NW 3.11 server netlab2.usu.edu appears in SLIST as
EDU-USU-NETLAB                                 [817BFE00][AA0004007E61]        
EDU-USU-NETLAB2                                [817B012C][           1]Default 
Netlab is my VAX running NetWare/VMS. Notice that the NW numbers are the
Internet numbers, but written as Novell hexadecimal digits. Netlab2 is
129.123.1.44, and netlab is 129.123.1.11. The internal network number is
always that of the IP address of the board closest to the main backbone.
So, the Internet assigns a unique domain (usu.edu, 129.123 here) and we divide
that into local items. We don't have to hire an administrator to answer the 
phone, call meetings, create a big database, and to globally assign idents 
according to some homegrown bright idea scheme. At any time in the future we 
could (and we do in fact) add a new site just by telling the ciscos about the 
site, and there is no collision of names or numbers. The new sites could be
in places we have never heard of before on other continents, if they follow
these rules.
	I wish to emphasize that this scheme is delibrately as unoriginal as 
possible: it is easy to explain in a paragraph, easy to implement, and rather 
useful in practice. The Internet authorities get all the paper shuffling work, 
and because they do this world wide they solve the uniqueness problem for us. 
We do nothing except create the usual local whimsical names for our local part. 
	The time to convert is NOW, not later. We did a campus with about 50+ 
NW file servers, scads of rprinters, more scads of .bat files, in a one hour
down time interval one bright morning.
	Lastly, to help the problem of TCP/IP access for folks sitting behind
NW servers we use the TCP/IP routing capabilities of our servers, and we also
use the unsupported Bootpfwd NLM (and matching upgraded TCPIP.NLM) written
by Don Provan of Novell. This routes Bootp requests to our central Bootp
server. Copies of these are found on both sjf-lwp.corp.sjf.novell.com and
netlab2.usu.edu, cd misc and grab archive bootp311.zip.
	Joe D.
Newsgroups: comp.sys.novell