X-Envelope-to: NOVELL@SUVM.BITNET
X-VMS-To: IN%"NOVELL@SUVM.BITNET"
X-VMS-Cc: JRD
Newsgroups: bit.listserv.novell
Date:         Thu, 16 Apr 1992 10:29:00 MDT
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         Joe Doupnik <JRD@USU.BITNET>
Subject:      Re: IP Tunnelling limits (practical and theoretical)

>From discussions on this list (although I was off for a while) and
>reading the TCP/IP transport supervisor's guide, there seem to be some
>practical limitations on IPTunnelling a large number of servers together
>across campus or an even wider area.  The guide recommends no more than
>ten peers for any node.  (p. A-5)  The reason given is that an IPX
>broadcast is duplicated and transmitted through the IP tunnel.  Fair
>enough, but I am still struggling in my own mind with a number of issues
>that will determine our strategy for connecting the campus through IP
>Tunnelling.  Most of these questions might be answered by:  Read this or
>that.  That sort of information would be great, but even better would be:
>We're doing this with nn servers on a nn Mbit network, and it works fine.
>
>1  What percentage of IPX packets are broadcasts?  (What design
>parameters can lower this?  (Eg. replies to GetNearestServer off)

        Few. Serving objects advertize themselves once per minute. File
servers do this for their name and their number, and additionally transmit
the parallel lists of "servers I have known" once per minute. The latter is
the meat of Novell's routing protocol mechanism. These latter lists get
rather large and constitute the majority of the admin overhead traffic.
Be aware that a person logging into a server generate a horrendous qty
of packets as things get setup, and if steps are not taken these will be
sent across the net. In addition, the shell can be set to send EOJ pkts
when each DOS program finishes; that's an additional source of junque pkts.

>2  Are people using 'unidirectional' IPTunnelling?  Ie Server A is a peer
>to B, but B is not a peer to A?  Would this affect performance?

        I think this won't work at all. Both sides have to agree to tunnel
to each other.

>3  Is there any way to return to your closest server upon logout?  In my
>environment I remain attached to a remote server if I've logged in there,
>and thus if I want to re-login to my closest server, I have to load
>LOGIN.EXE from the remote server. (Leaving enough time for a coffee break
>if the link is slow enough :-)

        No. That's a Novell routing issue and "closest" is a human perception.
Tunneling is designed to be totally transparent.

>4  I remember reading an early summary of the tests of tunnelling across
>a very wide area network.  Was there a more complete summary?

        I posted at least two or three of these things and bored half the free
world in the process.

>Gerrit Bos  Systems Analyst, Data Comm, Comp & Comm Services, U of Guelph
>            Guelph ON Canada N1G 2W1 (519)824-4120x3489 Fax:(519)763-1620

        A piece of advice. Avoid tunneling if you can. Instead fully route
IPX traffic. Today's routers (cisco etc) can be very very clever about
routing and conserving bandwidth. For example. Here in the State of Utah
we route IPX across the Internet. The ciscos at each point proxy advertize
on the local nets for serving objects on the remote nets. One copy of the
"things I have known" list is sent across the Internet every few minutes or
so, contrasted with once per min from each such object. This is an extremely
important savings of bandwidth because of the qty of advertizements. The ciscos
block the junque traffic and can be set to reject advertizments from local
concerns (printers, Net Port boxes, Sitelock, etc). Clearly, cisco etc routers
can impose security restrictions (which nodes can see others); tunneling is
a blind copying of literally everything.
        A fully routed IPX system looks just like a local one to the users. In
addition it is much faster than a tunneled one. The lowest priced cisco router
is around US$4500 after educational discount, and it is worth every penny.
We have looked at and used both tunneling and routing, and the answer became
very clear.
        Novell, on News, recently commented on the attitudes seen in some
places about managers wanting only one kind of protocol on the wire. They
called this a religious issue. That's a kind statement. What folks are saying
is they can't cope as net managers, even though the network is more than able
to accomplish these things. So if that issue arises at your site be prepared
to argue that IPX is neither better nor worse than IP than DECnet than LAT...,
and all are a whole lot better than Apple Ethertalk stuff (do I have a bias?).
Routers are built to work with all of these, if people would only read those
manuals.
        Joe D.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU