X-Envelope-to: NOVELL@SUVM.BITNET
X-VMS-To: IN%"NOVELL@SUVM.BITNET"
X-VMS-Cc: JRD
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Newsgroups: bit.listserv.novell
Date:         Tue, 6 Oct 1992 20:46:01 -0600
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         Joe Doupnik <JRD@USU.BITNET>
Subject:      Re: IP Tunneling - max # servers? WHY?

>In article <Oct.6.12.39.16.1992.29279@dorm.rutgers.edu> medici@dorm.rutgers.edu
>(Mark Medici) writes:
>>ag129@cus.cam.ac.uk (Alasdair Grant) writes:
>>>In article <01GPIAPRIFJY91X7C5@CC.USU.EDU> Novell LAN Interest Group
><NOVELL@SUVM.BITNET> writes:
>>>>I have yet to hear of one decent reason to restrict the backbone to IP only
>>>>traffic.
>>>>        Joe D.
>>
>>>What about "lack of multiprotocol routers"
>>
>>I don't see any definciency of multiprotocol routers in the market.
>
>Oh, they're in the market all right!  It's just difficult to make a
>business case (on a tight budget) for _buying_ them, when the only
>benefits are a slight performance improvement, and ease of maintenance
>(against claims that IP tunnelling is easier, of course).
        But the claims would be strange indeed. IP tunneling is point to point,
a la days of old. That's two points of a link. How many other points might be
involved and what interconnection diagram might one sketch? How will the
system grow over time?

>>> and "avoidance of interference
>>>from badly-configured LANs on the same WAN?"  Don't you ever get cases
>>>where some idiot starts spewing broadcast IPX packets all over the campus,
>>
>>With abut a half-dozen protocols, including IP, IPX and AppleTalk2 as
>>the major bandwidth consumers, this has not been a problem here.
>>Not necessarilly.  However, tunnelling certainly makes attempting to
>>troubleshoot this problem and most other WAN problems much more
>>difficult.  Not only do you have to decode the IP packet, but then you
>>have to unwrap the underlying protocol and decode it.  What tools
>>would you use to accomplish this?
>
>Well, one of the points of a tunnel is that everything goes through it.
>Surely that makes debugging _easier_?
        Ok, let's spell it out. Your favorite network monitor understands
only IP packets, and you tunnel in IP. Now you have lovely IP packets and
the contents of the data field are IPX packets. Unfortunately, protocol
analyzers aren't built to decode the data field according to a distinctly
different protocol so IPX remains a black box.

>>We have over 50 NetWare boxes, 150 AppleShare boxes, 100 DECnet boxes,
>>50 terminal servers, a few IBM mainframes and a couple thousand
>>UNIX/IP boxes all talking their native protocols accross our backbone.
>
>I'm impressed (really), but do you have a central number allocation
>authority?  Did you set this up before people started wanting to connect
>their NetWare systems to the WAN?
        My site is roughly similar. Of course there is centralized control
of things such as IP addresses. I can't imagine your site lacks that part.
Initially our NW servers were set willy nilly, and as soon as they wanted
connection to the backbone they had to follow some very simple rules. One
phone call, filling out one quick form, and that's that around here.

>>The biggest obstacle to opening the single-protocol WAN is getting
>>folks to realize that their familiar protocol of choice is not the
>>center of the universe.
>
>I don't think that is the case for us. We are quite new to IP too.
        Good. That is a relief to hear for a change in this business.

>The fact that Novell doesn't seem very happy with networking standards
>doesn't inspire confidence.  E.g. their dithering between DIX and 802.3,
>or their use of LSAPs. I believe they use global LSAPs, which sounds like
>a bad idea (please correct me if I'm wrong).
        An inference. Lans learn the hard way. Mainframe class networking
is no better, and in some cases has hardened so that changes are almost
impossible. The market for lans has changed so fast that what were excellent
choices for distinct lans are no longer the best choice for wan work. But then
wan technology has been gross overkill for PC based lans, and the major vendors
advocating their wan strategy for PCs have lost a bundle on the pushes. I am
not saying that IPX is a perfect protocol (far from it), but to be honest,
doesn't IPX route far more simply than say IP? How many times does one have
to explain/check subnet masks or default routes/DNS tables, or modify the
whole thing because one more level of routing is added (adding just one new
server behind another)? IP too has plenty of faults when applied locally.
I'll bet the extra cost in RFC-compliant asprin is larger than the cost
differential of simple vs multi-protocol routers.
        Pressures from users will force the site into supporting multiple
protocols, no matter how the network people feel about it. Just stick a PC
on the Comptroller's desk and a Mac on the CEO secretary's desk and that is
the end of the story.
        Joe D.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU