[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

16.0. "DECbridge to Manage Repeaters?" by RADBOX::ANDERSON () Tue Dec 17 1991 15:09

    Let's see if I understand this correctly.  To manage the repeaters (90c
    or 90t) the DECbridge 90 is required.  If I am correct, is it required
    that the DECbridge 90 be in hub with the repeaters, or can a single
    bridge be used to manage multiple repeaters, in multiple hubs, on an
    extended lan (RBMS, MOP cant be routed).
    
    The reasoning behind this question is that a customer has many small
    sites where only 1 or 2 repeaters will be needed, and the additional
    cost of a DECbridge makes the solution to expensive.  If a single
    bridge could be used to manage several repeaters at several sites this
    brings the cost down significantly.  I understand that each of these
    sites would need to be bridged if this option would work.  Thanks.
    
    Bill Anderson
    Portland OR

T.R	Title	User	Personal Name	Date	Lines
16.1	A 'bus master' must be in each hub	NOHOST::LEVIN	Bryan, LENaC Engineering, MLO3-3/U39	`Tue Dec 17 1991 17:25`	30
	Yes, you understand this correctly. The reason behind it, is that repeater management is NOT standardized in any LAN protocol (ie, there is no Ethernet or ISO 8802 compliant solution). So, what we, and other hub vendors have done, is to 'hide' the proprietary-ness of our repeater management scheme on a PRIVATE backplane. Yup, you guessed it, it's the serial management bus on the DEChub 90. Now, for the repeaters to be managed, there MUST be some connection between the manager (ie, the WGB or the NMA) and the objects being managed (the TMR or CMR). So, since the WGB is [currently] the only 'bus-master' on the hub, it MUST be connected to the asynch management bus where the repeaters sit. Of course, the NMA can be remote from the hub -- as long as there's an e-lan connection to the WGB (since, as you've pointed out, RBMS is an e-lan ONLY protocol). So, you can save money on having ONE NMA per e-lan, but for repeater management, you MUST have a WGB in each hub that is to manage the repeaters. In a future release, the NMA is planned to manage the repeaters, directly. In this case, it will follow the same rules as the WGB -- it must be connected to the private, asynch backplane management bus to talk to the repeaters. Sorry. .bl
16.2	This is better than most competitors	EMDS::SEAVER	LENAC Net Mgnt Mktg 223-4573	`Fri Dec 20 1991 14:56`	18
	Note this is no different than any other hub vendor. They all require an expensive management module to manage the repeaters in the hub. As Bryan points out all are managed thru a proprietary back plane protocol. (note- this module man be called a retiming module or some other name, but it is always needed for management). In DEC's case we offer the bridge which is actually a combination bridge (for isolation), back plane connector, and repeater manager. Most competitors do not offer the bridging function in their modules and cost a great deal more than we are planning to charge. Yes, we also require a separate agent, but that does not need to be in the hub and one agent can handle between 4 and 10 hubs easily before performance degrades. On top of that the bridge and or the agent can fail and it will not affect communication between the various ports within the hub. With competitor's gear, the individual ports on the concentrator could not communicate with anybody when the management/ retiming module is down. This type of robustness is a feature of the way we have implemented management.
16.3	what can you control from ELMS?	ROM01::CENCI	tuatha de' danann	`Wed Jan 29 1992 09:37`	12
	A customer, who has recently ordered DEChub, put me a question on whether you can "control" thin wires from ELMS. I think that what he means is the ability to use software commands to "isolate" or to "reconnect" the thin wire the bridge is attached to. I have never used neither ELMS nor DEChub. Can you help me answer that question, or point me to the pertinent documentation? Thanks a lot Fabio
16.4	DECbridge 90 control from ELMS	MEMIT::FORREST		`Fri Jan 31 1992 12:54`	18
	You cannot manage a DECbridge 90 that you get today with ELMS, since the DECbridge 90 you get today does not support the RBMS protocol. Also, since ELMS functionality was frozen before the DECbridge 90 development was completed, it does not support any of the uniqueness of the DECbridge 90. I understand too, that there will be no future updates to the ELMS product. The ELMS-like applications on DECmcc and DECmcc MSU can mostly manage a DECbridge 90 that has been upgraded to support the RBMS protocol. This upgrade should be available this quarter. Customers have to ask for the upgrade however, there won't be an order number or a charge for the software. We hope to have the DECbridge 90 fully supported by DECmcc and MSU using the appropriate bridge management functions/options. I know you can isolate the workgroup side of the bridge via MOP command today. I'm sure you'll be able to do that via the RBMS protocol too. jack
16.5	One DECbridge can manager two DEChubs	BSS::AMBER	Mark Amber, CXO3 LAN Mgr. (DTN)592-4645	`Thu Jul 02 1992 14:58`	7
	This is a bit late, but just for the sake of clairity... You can use ONE DECbridge90 to manage all the repeaters on up to TWO DEChub backplanes. Two HUBs can have their serial management bus and ethernet backplane bus connected together and ONE bridge can then manage all the ports. Of course, the two hubs have to be within reasonable proximity to each other.