Conference netcad::hub_mgnt

    
    
    	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. 

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

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

    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.