[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DEChub/HUBwatch/PROBEwatch CONFERENCE |
| Notice: | Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7 |
| Moderator: | NETCAD::COLELLA DT |
|
| 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 |
974.0. "DECHUB900 MANAGEMENT BY GENERIC NMS" by BBOV01::MACKENZIE () Wed May 11 1994 02:19
I am responding to a large Govt tender for the supply of LAN
hubs. I am bidding the DEChub900, DEChub One and the DEChub
90 range.
I am seeking assistance on the following sections that deal
with how could the hubs be managed htrough a "generic"
network management station (HP Ovenview, SUNnet Manager, or
possiblly PNV),
What scope and functionality to manage the DEChub900 really
exists in the absense of HUBwatch NMS or its avilability on
third party NMS.
Any assistance greatly accepted...
Tony
2.5 MANAGEMENT
2.5.1 General
Hub management software is required for the network
management of the hubs throughout the Queensland Transport
data network. The hub management software is required to be
integrated with a generic SNMP enterprise-wide Network
Management System (NMS). The requirements for this NMS are
the subject of a separate specification, Specification TU-004
Network Management System.
The assessment of hub equipment shall include consideration
of the functionality of the hub management software proposed
and its level of integration with the enterprise-wide NMS.
2.5.1.1 Mandatory
(i) Hubs shall support both in-band and out-of-band
management down to the port level.
The hub management software shall integrate with an
enterprise-wide SNMP based NMS. In particular :
(ii) The hub management software shall operate over the
generic SNMP enterprise-wide NMS hardware and software
platform with a shared graphical user interface (X11) and
Motif.
(iii) The hub management software/NMS shall have complete
support for all the hub management functions, including all
proprietary extensions to hub MIBs.
(iv) The hub management software shall comply with the
underlying NMS database.
(v) The hub management software shall utilise a common IP
discovery and mapping function (as opposed to separate
functions) that simultaneously provides network information
to both the hub management software and the NMS.
2.5.1.2 Desirable
(i) The mechanism for out-of-band management should have a
graphical user interface.
(ii) The hub management software/NMS should provide
automatic graphic representations of its products to
facilitate configuration and fault management.
2.5.1.3 Additional information to be provided
The proposer shall discuss all mechanisms for management of
the hub equipment such as:
* hub management software/NMS;
* Telnet access;
* console port/remote dialup access.
Discussion of these mechanisms shall include comparison of:
* functionality;
* user interface (e.g. command line, menu-driven);
* performance.
The proposer shall also provide details of the following :
* any limitations on the total number of devices that
can be managed by the hub management software;
* the module requirements to enable management (i.e.
whether a specific module required to provide management or
whether management functions are inherent in each hub
interface module);
* hardware and software platform requirements of the hub
management software/NMS;
* level of proven interoperation with a generic SNMP
enterprise-wide Network Management System (NMS).
2.5.2 Protocols/Standards
2.5.2.1 Mandatory
(i) The hubs proposed shall support management via SNMP
for fault and performance management. The hubs shall be MIB
II compliant as a minimum.
(ii) The hubs shall have current or stated future support
for all relevant management functions (i.e. configuration,
fault, performance and security) via SNMP, CMIS/CMIP and SNMP
II.
(iii) The hubs shall have current or stated future support
for RMON.
(iv) The hubs shall have current or stated future ability
to serve as a distributed network management engine to the
central hub management software/NMS (for local polling and
filtering).
For hub products where total management via SNMP, CMIS/CMIP
or SNMP II is not currently available, an estimated timescale
for delivery of this functionality shall be provided by the
proposer. Time to deliver RMON and distributed network
management engine functionality shall also be provided if
these features are not already available.
2.5.2.2 Desirable
(i) The hubs should have current or stated future support
for the OSF DME.
(ii) The hubs should have configuration and security
management via SNMP.
2.5.2.3 Additional information to be provided
The proposer shall detail all relevant management protocols
and standards supported, including any extended/proprietary
management mechanisms and MIBs.
2.5.3 Configuration Management
2.5.3.1 Mandatory
(i) The ability to distribute configuration software from
a central location is essential. The proposer shall provide
details of the mechanism (eg. Flash EPROM) used.
(ii) There must be a simple recovery path for the situation
where a downloaded hub configuration fails. The proposer
shall provide further details.
(iii) Local and remote support for activating/deactivating
hub ports and for resetting the hub.
(iv) Support for dynamic configuration. The proposer shall
provide further details.
2.5.3.2 Desirable
(i) The ability to maintain central back-ups of
configuration data for hubs.
2.5.4 Fault Management
The ability to accurately identify and resolve faults is
essential.
2.5.4.1 Mandatory
(i) The minimum diagnostic LED requirements are:
� active/inactive port;
� link signal;
� collision signal;
� power.
All other supported LEDs shall be detailed by the proposer.
(ii) A faulty port or interface module must be able to be
isolated from the rest of the network such that:
� for both stackable and modular hubs, the failure of a port
on an interface module will not impact the operation of other
ports on the module.
� For modular hubs with multiple expansion slots, the failure
of an interface module within the hub will not impact the
operation of other modules within that hub.
� For stacks, the failure of one hub in the stack will not
impact the operation of other hubs in the stack.
The operating conditions which prompt a port or
interface module to be automatically isolated shall be
described in detail by the proposer.
(iii) The hub must be able to carry out a hardware
self-test. The proposer shall provide details of any alarms
(eg. local diagnostic LED, SNMP trap etc.) that can be
generated by this test, as well as details of when this test
can be performed (eg. power-up, on demand).
2.5.4.2 Desirable
(i) The hub should be able to maintain a user configurable
error log.
(ii) The ability to configure the alarms, and the
thresholds which activate these alarms. The proposer shall
provide further details.
2.5.4.3 Additional information to be provided
For each type of wiring hub offered, the proposer must
provide details of the following:
* the type of faults (eg. line/port failure,
environmental problems) that the hub can notify, and describe
the resultant alarms.
* any self-test, self-diagnosis and automatic
re-configuration capabilities of the hub.
2.5.5 Performance Management
2.5.5.1 Mandatory
(i) All aspects of hub performance must be able to be
monitored via all management methods (ie. hub management
software/NMS, telnet, console etc). Statistics must be
available on a per-hub, per-module and per-port basis as
applicable. The measurable values must include:
� utilisation
� throughput;
� runt packet count/rate;
� jabber error count/rate;
� collision count/rate.
(ii) There must be user definable thresholds for
performance aspects such that an alarm/SNMP traps are
generated if these thresholds are exceeded.
2.5.5.2 Additional information to be provided
The proposer shall provide details of the presentation format
of the performance statistics for all different management
methods (i.e. hub management software/NMS, Telnet, console
etc).
2.5.6 Security Management
2.5.6.1 Mandatory
(i) The hub management software/NMS shall be capable of
keeping an audit trail of users executing management
commands.
(ii) Some form of security protection and user
authentication is required for management access for all
mechanisms (i.e. hub management software/NMS, Telnet, console
etc).
(iii) Different access levels must be definable for
different users or user groups.
(iv) The ability to assign a community string to the hub
for SNMP security.
2.5.6.2 Desirable
(i) The hub should support security protection on ports,
for example restriction of access to hub ports based on the
Ethernet address of the attached device. It must be possible
to enable and disable the security functions on any given
port.
2.5.6.3 Additional information to be provided
Any security features implemented in the hub shall be
detailed by the proposer.
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 974.1 | possible, but not worth it | NAC::FORREST | | Wed Jul 06 1994 19:00 | 8 |
|
Basically, if the generic SNMP manager is flexible enough, then
you could manage the DEChubs with a good deal of difficulty. Our
position is that the aggravation isn't worth it for the $2600 that
HUBwatch costs on a workstation.
We hope to be able to launch HUBwatch from the platforms you
mentioned before year end.
|