The following text is copyright 1993 by
Network World, permission is hearby given for reproduction, as long as
attribution is given and this notice is included.
By: Scott Bradner
So you say you are a
purest about networks and you want to run a pure TCP/IP network. You maintain
that this is cleaner and easier to manage than having all of "those"
protocols running around. Since all of your computers can support TCP/IP, why
would anything else be required? People who know how to run TCP/IP networks are
more numerous (i.e. cheaper) than those who can deal with the peculiarities of
AppleTalk and Novell's IPX, and who knows how DECnet works anyway?
I remember saying the
same thing once upon a time. If memory serves, the purity lasted a day or two
until it was pointed out quite forcefully that the majority of the major
research computer centers on campus ran VMS machines. Oh ,well. Expanding the
support to TCP/IP and DECnet would not be too bad.
This is the way the
"new" network at Harvard ran for quite a while, with TCP/IP &
DECnet the officially supported protocols. Since the Harvard network is one
where almost all buildings have their own router port, this decision meant that
all inter-building applications had to run over TCP/IP or DECnet. But there
were always those pesky users poking at the periphery, wanting to run AppleTalk
or Novell's IPX.
There was good reason to
not support these other protocols. No one I ever heard of thought that
AppleTalk (at that time AppleTalk Phase 1) could be used in a large network
without great pain and high overhead. (Well, perhaps some people at Apple
thought so.) IPX had about the same reputation.
Well, if you build it,
they will try to come. It is now easy to get tunneling functions in a number of
AppleTalk and IPX devices. Tunneling is the process of encapsulating one
protocol within another. One can tunnel TCP/IP in DECnet and SNA or AppleTalk
and IPX in TCP/IP. The result in the latter cases is a data stream that
consists of "normal" TCP/IP packets. These packets can be forwarded
over a backbone ( or the Internet ) on which the encapsulated protocol is not
welcome. The user now has a way around the restrictions on the backbone and at
first cut this looks quite nice.
The problem with this is
that you, as the manager of the backbone, have no idea what is going on. If (or
should I say "when") someone misconfigures one of those tunneled
AppleTalk networks, you have no way of using the features in your routers to
filter out the problem since all the routers see is IP and not the AppleTalk
inside. You are going to get blamed when the encapsulated protocol has a
problem but you don't have any control. It is better to bite the bullet and
learn to do the routing than let the users do tunneling.
The basic problem with
letting users tunnel the protocols you don't want to route is that you can't do
preventative medicine. If there is a single most common cause of problems in
attempting to extend IPX or AppleTalk support across a widely dispersed corporate
network it is that LAN ID's get misconfigured. Chaos is the result if the same
IPX network address is used more than once or if overlapping AppleTalk network
ranges are used within the same internet. The routers that are used to
interconnect the network can be programmed to only accept traffic from, and
forward traffic to, the specific list of network (not node) addresses that are
registered for a particular port. Implementing these types of traffic filters
does take some additional administration but it can almost eliminate the
problem of a misconfigured LAN in L.A. taking down the networks in Chicago.
Even if all of the LANs
are always in perfect addressing harmony you may not want the whole network to
know about all of the services that exist everywhere. Filters can be added to
some routers which block selected service advertisements from one area and
prevent them from being seen in another.
Some of this filtering
can be done if you are in control of the tunneling gateways, but most of the
existing products don't have filters as sophisticated as some routers now have
and all too often the manager of the backbone network does not have control of
these gateways.
Even if all of the above
problems are not an issue (The LAN addresses are always perfect and the world
should know about every service, or you have total control over all gateways.)
you actually may be making the traffic load on your network a bit worse by
doing the encapsulation. AppleTalk and IPX were originally designed to work in
an environment with relatively few LANs and servers. As the number of LANs and
the number of servers expands so does the network load caused by the passing of
routing information and service discovery or advertisement information.
Tunneling does not make this go away; it actually increases the size of the
data packets and thereby the network load by a few percent.
Letting your users
resort to tunneling rather than routing the protocols themselves turns you into
of a spelunker, exploring unmapped caves in search of what is going wrong with
the network hidden under your network.
The Harvard network
currently does route AppleTalk (Phase II only), IPX, TCP/IP and DECnet. It
works very reliably using a strong set of network addressing standards, heavy
filtering in the routers and other good management procedures. (I suppose that
it does help more than a little that the standards, filtering and procedures
were designed and implemented by some people well versed in actual network
management rather than by a person watching the fire from the sidelines --
i.e., not by me)
sob@harvard.edu