Conference netcad::hub_mgnt

    
    I tend to agree, but don't sell us short. I deal with customers who
    have competitive equipment and it's not always rosey. I agree we need
    to take extra steps here. For example, it would be very useful it we
    put a label on the side of the box indicating a firmware revision. If
    we did this, the person selling it could check it against the latest
    rev and update it before the customer got it. However, in all these
    cases, the VAR or Reseller IS RESPONSIBLE for installing a WORKING
    config. You need a mechanism to feed this back to corporate so we in
    the field can take this VAR or Reseller to task for simply drop
    shipping an item. These people buy NPB products at substantial discount
    so they can make money and they should work to earn that money. 
    
    The question of manageable configs may be a problem. That is why we
    have created the certification program to weed out these problems.
    Again, you need a mechanism to notify the team in the field that a VAR
    or Reseller has sold an incorrect config, so we can work this problem
    by getting the seller more training or a refresher course. 
    
    In regard to the firmware mismatch problem, another noter has suggested
    that when connecting to a hub, HUBwatch be modified to get the firmware
    revs and flag inconsistencies such as the hub as 3.1 and the other
    modules which are fully up to date. I think this should be done sooner
    than later. It would help us with customer satisfaction.

    re .1 - what certification program is that? I didn't know we
    had one. 
    
    The point I was trying to make is that we need to make things
    consistent from the customer's point of view. There should be
    a standard that for EVERY module that goes it a hub,
       
      o it can be autodiscovered by the hub manager or decagent 
        or decbridge
      o it has it own snmp agent in case it's not in a hub 
      o the firmware is available at ftp.digital.com 
      o etc... ad infinitum
    
    From a support perspective, the DECserver products are the worst
    offenders in these regards. Everything about them is an exception
    to the rule. For example, Joe Customer goes to upgrade the firmware
    on all the modules in his hub. He knows that he can go get the
    firmware at ftp.digital.com UNTIL he gets to his DECserver 900tm
    which is currently running NAS 1.3. 
    
    Well, Joe, being a resourceful guy, thinks: "Hey, I've got the 
    VMS cd-roms. I bet it's there", so he spends 20 minutes checking
    only to find out it's not there either. In frustration he calls the
    CSC only to be told that he has to order it if he hasn't already
    purchased a software maintenance agreement (which, of course, nobody
    told him about when he ordered the box in the first place.)
    
    Now this kind of thing may make sense to some vice-president somewhere
    who knows why Digital needs to recoup $$$$$ for that NAS software, but
    what Joe Customer sees is that he's got a rack full of modules and he
    can upgrade everything except this *&)*&^!! DECserver and Digital
    is going to make him jump through hoops to get the software.
    
    Our customers and VARS have all got the same problem we have: more to
    do than the hours in a day allow. What I'm suggesting is that we
    make buying and using our products as SIMPLE as humanly possible. This
    could be done by defining a straightforward set of rules for all
    these products and then abiding by the rules. In the competitive
    marketplace that we are in today, Digital cannot afford
    to treat customers as though they will put up with this kind of
    aggravation because they love us and won't go elsewhere. They will
    in a heartbeat. 
    
    Whew, got right back up on the soapbox again, didn't I? Sorry
    about that.   

Dan,

Sucks, doesn't it.  Hell, I work in engineering, and keep forgetting how
to configure things.

On the other hand, newer products are more consistent (even the DECservers 
are about to become good hub citizens).  Routers?  Uh, well, uh, they're 
routers and they're weird by definition.  But the Router Configurator
application will help muchly there.

Other clearVISN apps also becoming more pro-active in doing the right thing.

Unfortunetly, most of the 90 stuff is old and it's hard to justify the expense
of re-engineering them. ("Should $$$ go to the PE2000 or to the DECbridge 90?"
is a question with an obvious answer.)

As you may have heard, the HUBwatch agents file is (finally) going to that
big bit-bucket in the sky; its replacement has a lot of automatic stuff
built in to it.

Jon Danzak has whined for years about having a products-and-what-you-need-
to-manage-them brochure.  That's finally been written, and should address
most of the problems you've described.  (Whining pays off!)

Tom Hood
asleep at the soapbox

RE: .2

>    For example, Joe Customer goes to upgrade the firmware
>    on all the modules in his hub. He knows that he can go get the
>    firmware at ftp.digital.com UNTIL he gets to his DECserver 900tm
>    which is currently running NAS 1.3. 
    
>    Well, Joe, being a resourceful guy, thinks: "Hey, I've got the 
>    VMS cd-roms. I bet it's there", so he spends 20 minutes checking
>    only to find out it's not there either.
    
>    Now this kind of thing may make sense to some vice-president somewhere
>    who knows why Digital needs to recoup $$$$$ for that NAS software, but
>    what Joe Customer sees is that he's got a rack full of modules and he
>    can upgrade everything except this *&)*&^!! DECserver and Digital
>    is going to make him jump through hoops to get the software.
 
The $$$$ from selling DECserver Media and Documentation kits isn't the 
primary issue here.  The reason that the DNAS software (we think of it as
software rather than firmware) isn't on the ftp site and isn't on ConDist
CDs is that it is Export Controlled software.  

DNAS contains Kerberos (and soon SecurID) which contains DES encryption, 
which makes this software a munition of war in the eyes of the US Federal 
Government.  :-(  While we have the lowest _grade_ of Export Control 
(General Techical Data Unrestricted - Mass Market Elegibility), there are
_still_ some countries and persons in the world to which/whom we may not 
legally distribute DNAS.  The fines for violation of these laws can be up 
to $8.1M. :-(  

Software that does not have License Management Facility key-access technology 
may _not_ be on ConDist (and DNAS doesn't have LMF).  So it should be clear
why we also can't put it up on the anonymous ftp site.

Regards,

Dave Nelson
Technical Lead for DNAS

> makes this software a munition of war 

If there's someone in the next cubicle you don't like, execute
an instruction on your DECserver you know will cause a crash, and
then lop it over the wall and hit the deck!  KABOOM!!!

Or, more insidious:  Enable Kerberos on your DECserver, and aim
the ports at someone you don't like.  Guaranteed to cause death
within 70 years!

;-{)}
Always thinkin'
Tom Hood

    re .4 - thanks for the info, Dave. I guess I knew about the export
    stuff but I had forgotten. I just picked a poor example to make my
    point about consistency. It does explain why that guy in the turban 
    offered me an new Porshe Targa for DNAS 1.6. :-)
                                               

    RE: .0
    I just got back from talking to someone here in LKG who told
    me that there is a new box label which will have the firmware 
    revision in english (IE: the equivalent alpha-numeric shown in
    the product's console screen), and will also be bar-coded. 
    So this should mitigate future problems with not knowing ahead 
    of time what the firmware rev is of a product before breaking 
    the shipping box open. I was shown what the label would look like,
    and was told that the mfg. site in Augusta, ME. (SCI), is ready to
    implement this new label soon. Apparently this has been in the
    works and just recently got approved for use. 
    
    Bob
    

    
    "Ask and ye shall receive"

    Ok time for me to get on my soap box.
    
    Why oh why is there no TELNET deamon on the HUB 900 MAM.
    
    Hell it's got part of the TCP/IP stack with TFTP and Bootp. It seems to
    have enough CPU power to control a 900HUB with so many gigbits of
    bandwidth - why can't we TELNET to the console.
    
    Reason for this is. Customer with large number of HUB900 remote. Remote
    meaning REMOTE !!!! Some of them thousands of Kilometers away, many
    hundreds of K's away from the neatest town.
    
    Now picture a company that has to change their IP address because of a
    company wide split. Also picture a company that has'nt got IP address
    assigned to their VERY DOWN REV 900 modules but only to the hub and the
    IP services module.
    
    If I could telnet to the HUB 900 I could change the IP address of the
    MAM and the IP services and then assign IP address to each module using
    module redirect mode. 
    
    Without TELNET means chartering my own plane and about 1 months worth
    of work !!!
    
    2nd bug bear ----- Can someone please sort out proxy loading so that
    90% of our modules support it. Not every company has IP address up
    their sleave to waste on HUB modules.
    
    If at least we fix things so that 900TM repeaters support porxy
    firmware loading that that would relieve a LOT of problems.
    
    The only other method is to have a spare 'firmware update' IP ADDRESS
    and cycle that through each module that your firmware updateing. A long
    slow process and only goo if your right next to the hub - not halg a
    country away.
    
    Perhaps HUB engineers should look their test hubs in a cupboard and
    someone hid the keys so they know what it feels like when you can't get
    access to the beast - mighty frustrating I tell you.
            
    Boy you can see for miles on this Soapbox - Look theres 3COM way ahead
    of us ...
    
    Shaun
    Network Services Brisbane
    

    
    Ever noticed how many times in product reviews in magazines
    (Byte, DataCommunications, etc.), always they say:
    
    "To fully configure the DEC box we needed the SNMP tool
     HubWatch, no way to configure from the serial or a
     telnet console�
    
    Many customers complain about it
    

    
    
    Seems strange not being able to telnet to the powerful multi-switch 900
    manager but if you boot up ProbeWatch you can launch a telnet session
    to a lowly Packetprobe.
    
    As .9 suggests, the 900hub can do almost everything else bar a simple
    telnet.
    
    Is there some basic reasoning for this such as MAC address association,
    lack of memory, etc ?
    
    Another thing is the administration fields in the MAM console
    connections. Then fields are there but no mechanism (bar Netview) is
    available to put info into these fields. 
    
    Customers look at these issues and shrug their shoulders wondering
    which release will enable these obvious future abilities.
    
    Commonality is another major whine :
    
    	o console port connection of the HUB900		RJ45
    	o console port of the decagent90		DB25
    	o console port of the Brouters			DB9
    	o console port DECservers			port 1 (mmj/rj45)
    	
    
    You go to site with a laptop and many cables and connectors so we can
    put IP addresses into the modules and THEN try to use the SNMP
    management s/w to setup the rest of the parameters.
    
    What would be nice would be if there was a default IP address (such as
    16.x.x.x) which we could telnet to initially to setup SNMP connection
    parameters rather than the present method.
    
    I personally think the hub products are reasonally well intergated and
    there a lot of issues to take into account but the opposition is making
    life really hard with the capabilities they have over us.
    
    Thanks 
    
    John 

RE: .11
    
>    As .9 suggests, the 900hub can do almost everything else bar a simple
>    telnet.
    
>    Is there some basic reasoning for this such as MAC address association,
>    lack of memory, etc ?
 
There was a time when SNMP was considered the best thing since sliced bread,
and Command Line Interpreter forms of management were considered obsolecent, 
proprietary, and to be avoided at all costs.  How times have changed!  :-)
   
>    Commonality is another major whine :
>    
>    	o console port connection of the HUB900		RJ45
>    	o console port of the decagent90		DB25
>    	o console port of the Brouters			DB9
>    	o console port DECservers			port 1 (mmj/rj45)
 
The these products were all developed by different engineering groups, and
it shows.  The only one in Digital who used to worry about connector 
consistency at a global level was Ken Olsen.  Now no one does, obviously.   	
    
>    What would be nice would be if there was a default IP address (such as
>    16.x.x.x) which we could telnet to initially to setup SNMP connection
>    parameters rather than the present method.
 
Not a good idea.  That might work in Digital, or on an LAN w/o routers, but
once your packets have to cross a router, watch out.  What you might want
instead is autoconfiguring via DHCP or BOOTP.  I think the LAN independence
feature of the DEChub makes this hard, however.  
   
Regards,

Dave

>    	o console port connection of the HUB900		RJ45
>    	o console port of the decagent90		DB25
>    	o console port of the Brouters			DB9
>    	o console port DECservers			port 1 (mmj/rj45)

Actually, the same group did the 900, the DECagent 90, and the DECbrouters.
The different connectors are more a function of what was the most likely
standard for that week.  As you can see, we've all kind of settled down on 
the RJ45.

Also bear in mind that the DECagent 90 was first designed when dinosaurs
roamed the earth, and the DECbrouter 90's came out during the first ice age.
So, you got your choice:  Backwards compatability (which we do pretty well)
or backwards consistency (yeah, right).

    
 
>There was a time when SNMP was considered the best thing since sliced bread,
>and Command Line Interpreter forms of management were considered obsolecent, 
>proprietary, and to be avoided at all costs.  How times have changed!  :-)
 
    Precisely, the CISCO users mailing list has now a religous
    chat about the "obvious" advantages/disadvatages of
    Web-based against command-oriented interfaces.
     
    
>>    What would be nice would be if there was a default IP address (such as
>>    16.x.x.x) which we could telnet to initially to setup SNMP connection
>>    parameters rather than the present method.
> 
>Not a good idea.  That might work in Digital, or on an LAN w/o routers, but
>once your packets have to cross a router, watch out.
    
    In many sites, me and my customer would prefer to briefly reconfigure
    one PC or station as a last-resource possibility instead to wait
    for someone to bring the right cable/connector to set an specific
    address.
    
    Also, that could be an add-on since the MAM supports multiple IP
    addressses.
     

    
    re:13
    
    Backwards compatibility ????
    
    How about the DECagent90 (OK, very old but still alive), revision 3.0
    and 3.1 having restricted the total number of modules that can manage
    from 64 to 48 !!!!
    
    OK this is for support the new 90T16, ok.But last month I spent two
    hole nights reconfiguring a huge network in a big hospital because of
    that.To manage a couple of 90T16 I lost the control over more than 30
    modules.
    
    Happy end ? yes. Bring a new DECagent90 and reconfigure 30 hubs in
    order to manage DECservers by the DECagents and DECrepeaters by 90TS
    that fortunately the customer had bought some time ago.
    
    Backwards compatibility ? Not pretty well, I would say.
    
    Jordi Manchon
    

 >   Why oh why is there no TELNET deamon on the HUB 900 MAM.
 >   
 >   Hell it's got part of the TCP/IP stack with TFTP and Bootp. It seems to
 >   have enough CPU power to control a 900HUB with so many gigbits of
 >   bandwidth - why can't we TELNET to the console.
 

The bandwidth of which you speak is in the backplane, and as Jon Danzak is so 
fond of saying, it is the dumbest backplane in the industry (I'm paraphrasing
here). But the MAM doesn't do anything with the backplane bandwidth - the 
hub modules do.

BOOTP, TFTP run over UDP/IP. The part the MAM is missing is TCP. 
TCP is much larger and more complex than UDP. The complexity part is
not the problem - the code size is the problem. There is not enough
flash memory in the 900 MAM.

Please bring up your concerns about a telnet requirement to the product
manager.

Thanks
-Mike

    Folks -
    
    Just FYI - I passed Dan's base note up the line to the director of US
    sales (Giulio Gianturco) and US marketing (Earnest Williams).  It's
    long been my gripe that we do *NOT* clearly articulate what is needed,
    where and when to manage our gear.  We also do not keep it simple for
    the customer. 
    
    We build *EXCELLENT* products that you can stand on, bounce off the
    wall, plug in and still work.  But, if you're in Sydney and need to
    manage a hub in Hong Kong to change it's IP address - unless you've set
    up remote services to the hub console WAY in advance you're out of
    luck.
    
    Being more customer-centric on the marketing/management side would go a
    long way to fixing these issues.
    
    Regards,
    j

What are we now talking about here?  Are we talking about the ability
to remotely connect to the MAM's setup screens?

						-Shawn

    In the "For What It's Worth" department, one of the most common
    calls we get from customers is "I just plugged my 900ef into my
    hub and it doesn't work." They are often confused by the fact that
    so many of the modules automatically connect to the hub thinwire
    segment, but not the 900ef. So we end up walking them through how
    to connect port 3 to the backplane, etc. Ditto for the 900ee.
    
    So for future consideration, how about changing the default behavior
    of the 900ef to be connected to the backplane thinwire with the
    option of disconnecting it? (Yep, I can see how you could argue both
    ways on this one. Just bringing it up as something to consider...)