[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference netcad::hub_mgnt

Title:	DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:	Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:	NETCAD::COLELLADT

Created:	Wed Nov 13 1991
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4455
Total number of notes:	16761

3099.0. "Strategy when many people run HUBwatch" by CRONIC::LEMONS (And we thank you for your support.) Tue Dec 26 1995 01:55

    Our site has a complex networks that will be monitored and maintained
    by several dozen individuals, sometimes by dialing in over 28,800 bps
    modems from home systems or laptops.
    
    If I use HUBwatch for Windows, I'll need to install HUBwatch on the PCs
    of several dozen individuals.  All ready, this sounds like a problem.
    
    If I use HUBwatch for Digital UNIX, I can install HUBwatch only once on
    a Digital UNIX system, and throw displays to OpenVMS, Digital UNIX and
    (via eXcursion) Windows systems.  This sounds like a better deal than
    HUBwatch for Windows, in our environment.
    
    If HUBwatch/Netview/etc. supported some sort of client/server
    interface, I'd rather use NT, as I find NT much easier to manage than
    Digital UNIX.
    
    Thoughts?
    
    Thanks!
    tl

T.R	Title	User	Personal Name	Date	Lines
3099.1	Go with local apps....	NAC::LICAUSE		`Tue Dec 26 1995 11:35`	20
	Why tax your network twice......all of the snmp requests/responses then all of the X-displays? If these were all local, then you might want to install a few of each to let the customer decide for themselves which is most tolerable. That's really what is will come down to. How long do your users want to wait for display updates. If you're using this across dialup or WAN lines, you're really asking for some pain. Why not put the distribution on a server and have the clients either copy down the kit or install it over the network? The real issue is the speed of the tool. Using a slow tool will only frustrate users/network managers. If the tool is fast, but the network is the gating factor then you really have the same thing. I have tried running Hubwatch on a 100Mb Pentium across a dialup 28.8kb line and it is generally faster than throwing displays to an X display locally from a Cobra running Digital Unix. One persons opinion.....
3099.2		CRONIC::LEMONS	And we thank you for your support.	`Tue Dec 26 1995 12:14`	16
	Why tax your network twice......all of the snmp requests/responses then all of the X-displays? That's one of the points: I don't want to do that. If I use Windows NT, then every installation has to do snmp requests/responses. If I use Digital UNIX, then only one system does snmp requests/responses, but many displays use this system via remote X display. Why not put the distribution on a server and have the clients either copy down the kit or install it over the network? Installing the kit is not a problem. Getting at the data after the installation is the issue. tl
3099.3	Only run HUBwatch ONCE on a specific HUB.	MSDOA::REED	John Reed @CBO = Network Services	`Wed Dec 27 1995 15:04`	10
	Be VERY VERY VERY careful about multiple implementations of HUBwatch on your customer's site. There are many activities that require sequential SNMP commands to set up modules. (backplane configs, and port switching, etc). Ensure that only one user at a time actually runs HUBwatch in WRITE mode. I would impress upon them the need to know WHO is changing the network at any given time. Perhaps you could add a front end application that get's their user id, and only lets one person at a time perform SETS, and enters any other user in RO mode.