Conference netcad::hub_mgnt

    Hi,
    
    Firstly, as in the last note, the correct place for VNswitch questions is
    actually IROCZ::COMMON_BROUTERS (although perhaps the two conferences 
    should get merged because of the overlap).    
    
    >>> I just installed ClearVisn V1.1a (MCM V6) and had a lot of fun:
        
    me too
    
    >>>     - a VNswitch module will NOT work as the IP services agent. 
    
    OK, I didn't even try since I was installing to an existing hub, but it
    should work - according to the release notes anyway. I'll try this out
    later today.
    
    >>>     - When you click into a module and do a FILTER on PROTOCOL or
    >>>       ADDRESS, if you change the PROTOCOL or ADDRESS it aborts the
    >>>       MCM.  (i.e. filtering just doesn't work - isn't settable from
    >>>       MCM.)
    
    Known bug, worse on Windows 95 than Windows NT. If you'd read the 1.5
    release notes and READ ME FIRST, you'd have seen it. Filtering from 
    the command line is OK.
        
    >>> - If you put in a VNswitch module and don't have AUTOVNBUS enable
    >>> turned on you CAN create a VNbus and connect VNmodules but they don't 
    >>> appear to talk.  That is, turn OFF autoVNBUS enable, create a VNbus and 
    >>> pull VNmodules to the VNbus and one connect to your Ethernet and
    >>> they DO NOT TALK (i.e. you can't manage them except the ONE module
    >>> that you've connected to the Ethernet.  Bottom line - ENABLE
    >>> AUTOVNBUS if you want the VNs to talk.
    
    Umm did you upgrade these from V1.1 of the firmware ? I certainly
    didn't have this problem, although I did have the problem that the 
    VNbus was disabled on the VNswitches (since we upgraded them from 
    the V1.1 firmware). Once I enabled the VNbus on the module, it was 
    fine (with or without autoVNbus).
        
    >>> - You must give every VNmodule an IP address to manage it.  If you
    >>> don't, you can't click into it.
        
    Known restriction, unlikely to go away. 
    
    FWIW, I ALWAYS allocate 10 IP addresses to a hub anyway (and try and
    get my customers to do the same). That way you get 1 address for the 
    hub, 1 for each slot and a 'spare' to use for the field engineer's 
    laptop. Also, upgrading firmware is a helluvalot faster when each 
    module has it's own IP address (ie when you don't do a hub-assisted 
    flash update).
        
    I've also had the embarassment of on-the-customer-site training in the
    past, when things don't work out quite as I expected.
     
    Ryan,
    NPBU, South Africa
    

    Well, 
    
    ONE thing that we *USED* to toute with the hub was the ability to
    *CONSERVE* IP addresses - this is sometimes important to folks. Needing
    to allocation 10 IP addresses for 10 closets etc...gets a bit pricey if
    you have class C addressess etc.  It's annoying at best.
    
    Although a dirty little secret is that as images grow, there's not
    enough memory on the MAM to do proxy loads - so you'll likely (in the
    future) need to address individual modules anyway. 
    
    But, we *NEVER EVER EVER* tell people about this in any planning guide
    for a large installation - they wait, get bitten and - zap. (grumble!)
    This bit me at a client with about 15 hubs and 4 repeaters in a hub,
    because that was ALL they had in a hub we went around with roller
    skates addressing the things one friday night.
    
    Regarding the 'read me first' and 'release notes' - yes, which ones? 
    The EA, EX, EF, EE or MCM?   When you've just upgraded the things at
    11pm, get up at 6am, get to your first appointment at 8am, and at noon
    are installing 'em....there's not lots of time.  An abstract of all of
    the "GOTCHAS" in a ONE-TWO page 'read me first' would help.  I don't
    think that most of us in the field (covering huge geographies) have
    lots of time (i.e. a day) to play around with the modules, read, catch
    up, when we're not jumping from one crisis to the next. (i.e. fix that
    DECserver problem, no the FDDI NIC issue, I mean the Gigaswitch problem
    or was it the spanning tree on DECswitch problem..now where was I in
    those release notes...?) duuh.
    
    So yes, an abstract is in order for the field to quickly survive.
    
    Bottom line is - there are LOTS of quirks with it yet.  NOT the fault
    of anybody, but the field really is NOT staffed to support it.  GO
    CAUTIOUSLY with it for the next few. (At least that's my feeling)
    

>    Although a dirty little secret is that as images grow, there's not
>    enough memory on the MAM to do proxy loads - so you'll likely (in the
>    future) need to address individual modules anyway. 

Don't look for this to go away.

Some product already do "segmented MAM assisted loads" where the MAM doesn't
have to store the whole image.  The MAM feeds the image to the module
as it gets it.

						-Shawn

In V5, the MAM has no size limitation on firmware images for any
modules (except itself).  We were able to move to a strategy where
we get a block from the TFTP server and immediately pass it on to
the module, without requiring any changes in existing modules.
SInce the MAM no longer needs to store an entire module image,
there's no restriction on the size of the image.

	Dotsie 

J (is it your name?)

to be able to use a Vnswitch as a proxy agent for your DEChub 900MS you have to
assign an IP address to that VNswitch and an IP address to the MAM

After that you will be able to manage your DEChub 900MS simpling using the MAM
IP address. (I seen that's the only way to see the backplane if you have on
VNswitches in your DEChub 900MS)

Regards
Francesco