NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/bit/listserv/biglan/71

Text File | 1992-09-07 | 11.4 KB | 268 lines

Comments: Gated by [e-mail]
Path: sparky!uunet!uvaarpa!darwin.sura.net!paladin.american.edu!auvm!SUVM.BITNET!BIG-REQ
Message-ID: <[e-mail]>
Newsgroups: bit.listserv.big-lan
Approved: [e-mail]
Date:         Fri, 4 Sep 1992 14:55:52 EDT
Sender:       Campus-Size LAN Discussion Group <[e-mail]>
From:         [e-mail]
Subject:      BIG-LAN Digest, Volume 4, Number 58, Friday, September 4, 1992
Lines: 256

BIG-LAN DIGEST           Friday, 4 September 1992      Volume 4 : Issue 58

Today's Topics:

                           Re: hubs that filter
                       Re: CAMPUS ETHERNET CRASHES
                     Re: 10baseT hubs with filtering
                          Re: Multi-Port Bridges
                      Re: experience/security issues

Moderated by John Wobus, Syracuse University

Relevant addresses:
                                  Internet                BITNET
Submissions:              [e-mail]     BIG-LAN@SUVM
Subscriptions:    [e-mail]     BIG-REQ@SUVM
LISTSERV/Archives:       [e-mail]    LISTSERV@SUVM
Moderator:                [e-mail]              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

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

Date: Wed, 2 Sep 92 09:58:59 -0400
From: [e-mail]  (James B. Van Bokkelen)
Reply-To: [e-mail]
Subject:      Re: hubs that filter

    The method varies a little from vendor to vendor, but the hub essentially
    learns or is told what ethernet Mac addresses are down each port and
    scrambles the data portion of those packets not destined for that Mac
    address.

If it "learns", then it's dependent on the interface sending something.
If the interface doesn't send anything (most LAN monitors don't by default),
then it can either send nothing (which means that you can't just connect
a random special-purpose server to a port and have it work), or everything
(which defeats the purpose).

If it is "told", then you have a maintenance nightmare, particularly in
the case of machines which run different protocols at different times
(and thus whose MAC addresses may vary).

James B. VanBokkelen        2 High St., North Andover, MA  01845
FTP Software Inc.        voice: [phone]  fax: [phone]

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

Date: Wed, 2 Sep 1992 11:39 EDT
From: [e-mail]
Subject:      Re: CAMPUS ETHERNET CRASHES

Wayne,

I have seen at least four different causes of dropped LAT sessions:

1. Trying to use a multiuser VAX/VMS system as a DECnet router.

When there is an error in the middle of a routing table update,
the VMS routing software issues a hardware reset command to the
ethernet interface. This causes all sessions that have I/O in progress
to be dropped. DEC is well aware of this problem.

Fix: Move all DECnet routing to relatively unused systems
or invest in dedicated routers.

2. Having more LAT hosts than the the LAT terminal server can handle.

Older LAT terminal servers have limited storage for their host tables.
When a new LAT service becomes visible, the server will drop some other
random service, even if it has active sessions.

Fix: Use service classes to limit the hosts served by specific servers,
or invest in newer servers.

3. Noisy terminal lines.

If the terminal server thinks that it has seen a <break> character,
it will go to the "Local>" prompt.
In this case, the original session is still available and can
be recovered by issuing the terminal server command "Forward".

Fix: rewire the terminal lines, using heavier guage twisted pairs,
maybe using shielded pairs, and minimize the number of splices;
or invest in more terminal servers so you can put them close to
the terminals.

4. Practical jokers.

Some people like to set the "break" and "forward" command codes
to characters which are frequently typed. Most people aren't even
aware of this feature.

Fix: punitive action or peer pressure.

I hope this helps.

Selden E. Ball, Jr.
(Wilson Lab's network and system manager)

Cornell University                 Voice: [phone]
Laboratory of Nuclear Studies        FAX: [phone]
Wilson Synchrotron Lab            BITNET: SYSTEM@CRNLNS
Judd Falls & Dryden Road        Internet: [e-mail]
Ithaca, NY, USA 14853-8001   HEPnet/SPAN: LNS61::SYSTEM = 44283::SYSTEM

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

Date: Wed, 02 Sep 92 08:38:47 -0700
From: Donald R. Proctor     (510/596-3828) <sybase![e-mail]>
Subject:      Re: 10baseT hubs with filtering


> | Among the options for dealing with this seem to a multi-port bridge device
> | that would prevent packets from being sent to "non-secure" jacks, by
> | filtering the frames on all jacks except for the one to the addressed
> | device.

> AT&T makes a 10BASE-T "SmartHUB" which does this. It jams data on all ports
> other than the one with a matching configured MAC address. It can also track
> movement of MAC addresses between ports. Price is about twice that of regular
> 10BASE-T hubs. I haven't had direct experience with them yet, as we're having
> a hard time getting a supplier to deliver one!

> Andy Hooper, Queen's University

I see two main problems with this approach to LAN "security."  First, it
assumes a one-station-per-port architecture, which precludes attaching
anything but an end station to the hub.  Second, it does nothing to foil
Ethernet "spoofing," in which a station alters its Ethernet address to
match that of a legitimate station.

Why wouldn't you just install a high-speed multiport bridge in this case?
This will also do MAC-level filtering, plus deliver the full 10Mbit Ether-
net bandwidth to each user.

Don Proctor

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

Date: Wed, 02 Sep 92 09:43:00 -0700
From: Donald R. Proctor     (510/596-3828) <sybase![e-mail]>
Subject:      Re: Multi-Port Bridges


Bob Gentile <[e-mail]> writes:

> At West Chester University we are laying fiber between 42 buildings, and
> will have 1,200 PC workstations running on 10 Base-T.  Initial traffic
> will be mostly software download, E-mail, and terminal screens from an
> IBM host.  Heavy imaging and video traffic are a couple of years in the
> future.

> For management reasons servers (15-20 486 PCs) will be in a central
> location.  Fiber will interconnect building concentrators and servers.  A
> multi-port bridging design offered by Cabletron seems attractive.  It is
> much less expensive than routers, is faster, and less complicated.  Routers
> can always be added, but we arn't sure why they are need now.  Routers also
> will be much more difficult and expensive to upgrade to FDDI.

Bob, I'd like to point out a couple of issues you may not have considered.

First, I don't think anyone would recommend setting up a bridged network
with 1200 nodes today.  A good multi-port router is no more expensive than
a good multi-port bridge (the Cisco and Alantec offerings come to mind),
and the payoff of implmenting a routing infrastructure early in the game
can be enormous.

The hub-based "low end" bridges are cheap, but are often lacking in per-
formance and diagnostic features.  While nearly everyone claims to forward
Ethernet packets at "wire speed," some vendors publish data based only on
minimum-sized (64k) packets.  Also, it's worth asking yourself how you'll
troubleshoot a problem the first time your beeper goes off at 3:00 AM...
With the Cabletron bridges we used to use, it meant driving into the office
and power-cycling the bloody things.

While you won't find any "plug and play" IP routers on the market, in most
cases they take only a few minutes to configure once you get the hang of it.

> The concern that we have with multi-port bridging is that broadcasts will
> be sent across all the segments.  Multi-port bridges will do filtering,
> and "learn" paths between devices, which can help reduce broadcast traffic.
> SNMP will help control broadcast storms.  Is this enough control?  Is it
> worth paying 3-4 times as much for a routing solution?

Broadcasts could certainly be a problem for you; multi-port bridges will
provide no help here.  You'll also find that a routing scheme will provide
huge benefits in fault isolation.  For example, what are you going to do
the first time a user starts seeing "duplicate IP address" messages on
his console, with a 3Com Ethernet address?  In a large bridged network,
this kind of problem can take weeks to solve.

We're just finishing up with a fairly painful conversion of a fully-bridged
1500-node worldwide network to a routed topology.  My advice to anyone
still in the design phase is to deploy the routing infrastructure early.

> Any advise and especially any experience with multi-port bridging will
> be appreciated.  Thanks:  Bob Gentile   RGENTILE@WCU  [phone]

Don Proctor
Sybase Computer Systems

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

Date: Fri, 04 Sep 92 14:48:39 -0400
From: "John M. Wobus" <[e-mail]>
Subject:      Re: experience/security issues

Linda Drake, CU Comp & Networks Srvs, writes:

>We're in the process of helping one of the campus ROTC units network their
>PCs with NetWare.  Our experience from working with other groups is they
>would greatly benefit from a connection to the rest of the campus (email,
>CWIS, gopher, etc.) not to mention the rest of the world, but they're nervous
>about the security implications.  Because this is our first experience with
>ROTC, we don't have a good understanding of their applications software and
>are hesitant to assure them that there won't be any problems.
>
>Have any other campuses encountered something similar?  Are you familiar with
>the software they run to communicate with "headquarters" and how that might be
>affected by a network connection?

This is not a helpful answer, just some obvious discussion about the
problem.  The problem of providing a secure environment for one LAN within
a campus or for a class of users who are spread throughout a campus is
certainly one that faces every college and university: any department that
wants to keep grades in a database, or the payroll, yet wants the
networking convenience of attaching them just once, through a LAN to a
campus-wide set of services will face a problem like this.  I suspect many
sites are not real willing to talk about the problems a lot because they
have a gateway here and a gateway there and their security depends
somewhat on the fact that no one understands how it is all put together.
All I'll say about our own site is that I'm not entirely comfortable with
the security as is and have not been pushing for expansion in the area of
applications with security requirements.

If it is a LAN that needs isolating, there are tricks you can do with a
router that supports access lists, or with a firewall gateway.  Also, a
Unix host attaching two LANs which does NOT route between them can
allow access to whoever has usernames on the Unix host but no one else
(if the Unix host is administered in a secure fashion!)

John Wobus
Syracuse University

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


End of BIG-LAN Digest
*********************