Newsgroups: bit.listserv.big-lan
Date:         Tue, 26 Jan 1993 15:10:26 EST
From:         BIG-REQ@SUVM.BITNET
Subject:      BIG-LAN Digest, Volume 5, Number 4, Tuesday, January 26, 1993

BIG-LAN DIGEST           Tuesday, 26 January 1993       Volume 5 : Issue 4

Today's Topics:

                        running NON gel-filled UTP
                           Routers as backbones

Moderated by John Wobus, Syracuse University

Relevant addresses:
                                  Internet                BITNET
Submissions:              big-lan@suvm.acs.syr.edu     BIG-LAN@SUVM
Subscriptions:    big-lan-request@suvm.acs.syr.edu     BIG-REQ@SUVM
LISTSERV/Archives:       listserv@suvm.acs.syr.edu    LISTSERV@SUVM
Moderator:                jmwobus@syr.edu              JMWOBUS@SYREDU
Anonymous ftp archives:           syr.edu

Note: BIG-LAN is redistributed through many mailing lists at other sites
run by other individuals.  If you subscribe(d) through such a
"redistribution" list, you will need to remember its owner.

syr.edu also has a copy of the BIG-LAN "FAQ" memo (answers to frequently
asked questions) under the path information/big-lan/big-lan.faq

BIG-LAN is also available via netnews, through newsgroup
bit.listserv.big-lan.

----------------------------------------------------------------------

Date: 25 Jan 93 17:41:47 U
From: "Dave Clark" <dave_clark@igppqm.ucsd.edu>
Subject:      running NON gel-filled UTP

                      running NON gel-filled UTP level 5 underground
Experts-
My goal is to try to design a point-to-point level 5 UTP copper and fiber
network from approx 100 desktops spread over three new buildings to a single
MDF in a fourth new building via new underground conduit.  The runs would all
be less than 330' from desk to MDF (ah, point to point flexibility) but would
mean having to figure out a way to safely lay non-gel-filled level 5 UTP cable
in an underground conduit system for no more than 250' of each cable's total
length.
My concerns are not only that gel-filled level 5 UTP cable doesn't exist, but
that just the existence of water vapor - over long term - may affect the cable.
 I thought about running it in innerduct and perhaps purging the tubes with
nitrogen, then sealing.  In light of my desire to attempts to keep the design
point-to-point, can anyone offer any insight/wisdom/an alternate solution on
the moisture/gel-filling requirement?
Thanks-
Dave Clark
dclark@ucsd.edu
Institute of Geophysics and Planetary Physics
Scripps Institution of Oceanography
University of California San Diego

-------------------------------------------------------

Date: Tue, 26 Jan 93 14:16:59 -0500
From: "John M. Wobus" <jmwobus@mailbox.syr.edu>
Subject:      Routers as backbones

Dave Williams writes:
>I'd like to hear from any large sites that have routers configured as
>backbones.  There's lots of marketing hype from the router companies
>on why you "need" to do this, but very little in the way of hard info
>on configuration, performance and pitfalls.
>
>Our current configuration consists of about 400 SPARC clients fed by 13 Sun
>4/490 servers. Each server has multiple NC400 Network Co-processors (one per
>client network), 2 IPI controllers and 6-8 IPI disks (some Saber's, some
> Elites)
>
> [lots of text, charts, and ideas deleted: see original posting]

Our network is more general-purpose than yours: lots of PCs and
Macintoshes in lots of buildings in addition to workstations.  We went
to a "backbone in a router" strategy simply because it was the least
expensive way to build a routed campus network.

We do have some workstations & servers and worry about the same issues
that are worrying you.  You seem to have done more measurement and
experimentation than we have.  Our situation is a bit different: we
have probably fewer workstations than you do and while some are grouped
together, others are scattered all over campus among our PCs and
Macintoshes.  Also, we have a large timesharing Unix system which
shares data and a lot of applications with the workstations.

We chose to have one large server for user data (home directories) and
one large server for applications software.  Right now, both the
servers are hanging on a single Ethernet which runs into a router. The
timesharing system is on a different Ethernet, there are a couple of
Ethernets that have between 5 and 20 workstations, and other
workstations are scattered around the campus:

     |                  |                 |    |        |        |
     +--Software        |                 |    |WSs     |WSs     |
     |    server        +---Timesharing   |WSs | &      | &      | . . .
     |                  |    system       |    |micros  |micros  |
     +--Data server     |                 |    |        |        |
     |                  |                 |    |        |        |
+----+------------------+-----------------+----+--------+--------+--------+
|                  Router                                                 |
+-------------------------------------------------------------------------+

To make this work and to help address the problem of WSs scattered all
over the place, we run no diskless nodes: temp and swap are on a local
disk.

We see the Ethernet with the two servers as the bottleneck and plan to
add more Ethernets to the servers without turning on routing.  For
example, there might be a single Ethernet that ties together the
Applications server and Data server with the Timesharing system.  This
would offload some traffic from the router as well as two Ethernets.
An Ethernet could link the servers with group of co-located
workstations in similar fashion.  Another idea is that we could
duplicate the software server for performance if necessary.

A practical consideration that has faced us is whether we can use the
dual paths for redundancy, either through the use of manual commands,
or through automatic adjustment of routing.  Since we use the
automounter, we have had to think about how we might accomplish this
and haven't tested a solution to our satisfaction.  In any case, I am
not a big fan of redundant connections: they are necessary in WANs,
they might be useful and manageable on a Campus LAN for tying together
a specific set of routers that use a good, fast-converging routing
protocol, but a Campus LAN with an odd redundant link here and there is
likely to create more problems than it solves.

We have dreams of servers on an FDDI backbone with routers linking the
backbone to individual Ethernets.  So far, I have not been too
impressed with FDDI.

John Wobus
Syracuse University

-------------------------------------------------------


End of BIG-LAN Digest
*********************
Newsgroups: bit.listserv.wpwin-l