[comp.sys.novell] Wide Area Novell Networks

haas%basset.utah.edu@cs.utah.edu (Walt Haas) (12/29/90)

There has been some local discussion of setting up a Novell network
serving a wider area than just the University.  As far as I can see,
there are three technical shortcomings in the Novell IPX protocol that
would make this difficult:

1) No end-to-end checksum.

2) RIP is dumb, has high overhead.

3) Flat name space would be hard to administer.

Unless/until Novell makes their protocol smarter, one possible option
would be to encapsulate IPX in TCP/IP and use the usual Internet transport,
routing and naming mechanisms.  Is anybody out there working on this?

Thnaks in advance  -- Walt

tom@rsp.UUCP (Thomas Ruf) (12/29/90)

haas%basset.utah.edu@cs.utah.edu (Walt Haas) writes:

>1) No end-to-end checksum.
>2) RIP is dumb, has high overhead.
>3) Flat name space would be hard to administer.

>Unless/until Novell makes their protocol smarter, one possible option
>would be to encapsulate IPX in TCP/IP and use the usual Internet transport,
>routing and naming mechanisms.  Is anybody out there working on this?

Our IPX over IP encapsulation scheme solves problem 1), i.e we use
UDP with checksums.
However 2) and 3) are "as is", i.e "dumb" in our solution.
One way to get rid of RIP and SAP would be an encapsulating router that
derives the RIP and SAP info from a link state protocol on its WAN port
and advertizes this information on the LAN port as usual.
-- 
Thomas Ruf	tom@rsp.de	Schneider & Koch GmbH	Schneider & Koch, Inc
{uunet,mcvax}!unido!rsp!tom	West-Germany		Palo Alto

haas%basset.utah.edu@cs.utah.edu (Walt Haas) (12/30/90)

I'm forwarding the following at Jim's request:
======
To: haas@cs.utah.edu (Walt Haas)
Subject: Wide Area Novell Networks
Date: Sat, 29 Dec 90 14:15:06 PST
From: Jim Forster <forster@cisco.com>

Walt,

I made a reply to your article in comp.sys.novell, but it looks like news
is *^&$^&# here, so I'm not sure if it made it out.  I'll keep trying, but
may not get a chance to work on for the next several days.  Here's what I
wrote.


  -- Jim


Newsgroups: comp.sys.novell
From: forster@cisco.com (Jim Forster)
Subject: Re: Wide Area Novell Networks
References: <1990Dec28.120404.19912@hellgate.utah.edu>
Sender: forster@cisco.com (Jim Forster)
Reply-To: forster@cisco.com (Jim Forster)
In-reply-to: haas%basset.utah.edu@cs.utah.edu (Walt Haas)
Distribution: world
Organization: cisco Systems

I basically agree with Walt's observations, but have a comment on two of them,
and a few to add.

>2) RIP is dumb, has high overhead.

Certainly dumb, but is the overhead really that high?  Xerox has run a
large XNS internetwork for many years.  Their RIP is identical to IPX RIP
as far as route selection is concerned.  They have somewhere between 500
and 700 nets advertised, and somewhat fewer routers.  If the overhead is
indeed too much for slow trunks on the backbone, its pretty easy to allow
configurable RIP update timers, so you can slow down the regularly
scheduled updates.  Everyone connected to the same net must agree on the
timer parameters, and you should send flash updates when something changes,
but other than that there's not a big problem, and it can solve the RIP
overhead problem.  That's what we did in our latest release.

>3) Flat name space would be hard to administer.

True.  We recently added what we call SAP filters to our routers, so you
can modify the flat namespace.  Routers can selectively block SAP
advertisments (on the basis of SAP type or source address).  A likely
application is to block advertisement of all but certain globally important
fileservers at the boundary between a region (or campus, or building) and a
backbone.

This improves the situation somewhat, as the total number of names visible
at any client or fileserver can be limited to a reasonable number, independant
of the total number of server on the net, and because each area is free to use
whatever names they like for their private servers.

One problem Walt didn't mention, which is IPX shares with AppleTalk, is
that the diameter of internets is limited to 16 by the Transport Control
field (hop count) in the IPX packet.  This problem can be managed by
engineering the network into a hierarchy, rather than an arbitrary mesh, so
that the number of hops from anywhere to the backbone is limited to 3 or 4,
and the number of hops across the backbone is similarly limited.


With all of this, I think that the protocol, as is, can support a network
consisting of thousands of servers, a thousand or two thousand nets, and a
thousand routers.  I'm waiting for someone to do this.

One problem I see with encapsulation in IP is that you will probably have
to manually configure at each encapsulating router, a table of XNS address
to IP address mappings.  This is not a problem for a small net, but seems
unwieldy for large nets.  As was mentioned, Banyan supports this, and users
that have used it on large Banyan nets complain that it a big pain because
of this, and are switching to native Banyan routing throughout the entire
net.


Jim Forster
cisco Systems


PS: What's the largest Novell net known?
======
To: haas@ski.utah.edu (Walt Haas)
Subject: Re: Wide Area Novell Networks 
In-Reply-To: Your message of Sat, 29 Dec 90 17:34:18 -0700.
             <9012300034.AA01051@ski.utah.edu> 
Date: Sat, 29 Dec 90 16:41:08 PST
From: Jim Forster <forster@cisco.com>

>> Thanks for your very constructive comments.  Do you happen to know the
>> speed of the serial lines that Xerox uses in their network?  

I think their slowest lines are 56k, and RIP consumes a signficant fraction
of the line.

>> One concern I have is that we will probably want to include some small,
>> poor public schools on a statewide Novell net.  That means slow
>> connections to save money, and large RIP tables could completely consume
>> those connections.

Thats what the configurable update timer solve.  Its per-interface, so you
just turn it way down on both ends of a slow line, and let it default on 
the LANs.

Well, my news system is still wedged.  If you're up for it, I'd appreciate
it if you could post this dicussion.

Thanks,


  -- Jim