| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1036.1 | go get em! | KAOFS::S_HYNDMAN | Acronym Decoder Ring Architect | Fri May 27 1994 10:48 | 53 |
|
I can't address the subnet mask questions but might be able to help
with the Spectrum and Cabletron.
You should be able to compete very sucessfully against the MMAC stuff
on technology. They have only 3 channels compared to our 14. The first
channel A is ethernet only. Channels B & C are part of the Flexible network
bus. The repeater modules which connect to channel A can not connect to
any other channel. The repeater modules which connect to channel B and
C can not connect to channel A. Inorder to inter-connect these channels
requires a bridge module such as an EMME. Also they require a slot for a
management module. Last time I looked they did not have a multi port 10/100
bridge. What you end up having to provide is two bridges in the hub
which eats up valuable slots. You must purchase two different
repeater types is you want to use all three channels for ethernet
(TPMIM for A channel, TPR for B & C). Other irks are the EMME module
has only 15 pin AUI connections so most time you need external maus to
connect the hub to the network which is a pain to cable. The customer
would also be buying a dying technology. Cabletron has their new MMAC
Plus hub but none of the MMAC modules fit in it, so there is no
investment protection. In short you should be able to kill the MMAC
from a technical standpoint. They are stronger with more module
options than we have currently but that is changing.
I have not seen the new version of Spectrum. I can only speak about
version 2. It will kill a small system. It is rather piggy. Also it
requires considerable customization as it is not easy to use out of the
box. The reporting package was not the best. The tool requires that
you adapt to the way it is structured rather than the other way around.
It requires that everything gets modeled for it to understand it. I'm
sorry I don't think that way and don't feel I should have to.
Every part if Spectrum is an option (Spectro server, Spectro graph,
command line, etc.) and every option you want to manage requires you buy
the equivalent spectrum module. For example if you buy one new module type
(ie. EMME) you must buy the EMME software module for Spectrum ( and spend
the time to load and configure). This is a hidden cost that most customers
overlook. Spectrum doesn't have much in the way of ISV support. We
don't currently have much on OSF/1 either however through the Netview
association we should have plenty more. You should be able to compete
very well against Spectrum with Netview; easy of use, better
performance, open and accepted api, openview technology, strength of
IBM and Digital partnership (DECnet support), blah, blah, blah.
I think you have an excellent story to tell when compared to
Cabletron. Hope this helps.
Scott
p.s. Don't forget probewatch. Also I had problems with the performance
stats that their management modules reported. They consisistently were
in accurate about number of hosts and collision when compared to
analyzers connect to the same segments.
|
| 1036.2 | a couple of answers about HUBwatch | SLINK::HOOD | I'd rather be surfing | Tue May 31 1994 12:12 | 18 |
| And a couple of notes about HUBwatch.
(1) There is no limit to the number of agents HUBwatch can manage.
(2) There are no plans for HUBwatch to manage other vendor's products, per se.
HUBwatch is currently focused on Digital network products (DEChubs and
the GIGAswitch, with some others in the future).
We are trying to make some aspects be a more generic (for example, the
DECbridge 900 / GIGAswitch bridge summary window in V3.0 is pretty much
a generic IEEE SNMP bridge management window, and the DECbrouter windows
will currently display some info for the Cisco IGS brouter). However,
the windows are keyed to sysObjectId, and right now we look for specific
values there. We do not have a general-purpose sysObjectId parser that
would allow management of Acme Terminal Servers or Acme concentrators.
Tom Hood
HUBwatch
|
| 1036.3 | are there some comment]s about netmask issue in the DEChub 900 family | MXOV06::LERIOS | | Tue May 31 1994 14:19 | 16 |
|
Hi,
At the begining thanks Scoott/Tom for your comments.
I would like to know if there are some additional information about what we
are going to do with the netmask issue in the configuration of our
DEChub 900 products.
Since a technical point of view maybe this is a stupid thing however
the customer is still asking us about this aspect.
thanks in adavnce and best regards
Julio
|
| 1036.4 | | QUIVER::SLAWRENCE | | Thu Jun 02 1994 19:09 | 18 |
| We've gotten quite a bit of feedback on the issue of not being able to
configure netmask.
To summarize the current situation:
o As far as getting your packets delivered is concerned, whether
you are using routers or not, the scheme that we use does work.
Purists will argue, but in some ways the subnet mask is an
optimization. You _do_ need to configure the default gateway on any
module assigned an IP address, and on the IP Services module for the
hub manager (whether or not that module has an IP address of its own).
o Our strategy does mess up auto-topology applications like PNV.
This was a use of the subnet mask that was not considered when the
approach was formulated.
Correcting all this (making subnet mask configurable) is in the running
for the next round of development, and is running very well.
|