Filter
Top Products
ADC Telecommunications, Inc.
94 C
HAPTER 5: MULTI-CHASSIS SUPPORT
About Multi-Chassis Support
The purpose of multi-chassis support is to allow network administrators,
from a single session, to access and manage multiple chassis as a single
group. When a network administrator connects to a chassis that is a member
of a multi-chassis group, the administrator can also access all other chassis in
that group without having to connect to each chassis individually.
To become a member of a multi-chassis group, each chassis must have
multi-chassis support enabled and must be configured with the same group
name. When a chassis is configured with a group name, the chassis registers
its name with the Jini™ lookup service, which acts as a directory that enables
all chassis in the same group to find each other.
When planning multi-chassis support, consider that each Cuda 12000 can
run the Jini lookup service, but the service does not have to be enabled on
every Cuda 12000. Refer to “Planning Multi-Chassis Support” on page 96
for more information on planning multi-chassis support.
To access the multi-chassis group, the network administrator logs in to one
of the chassis in the group. The network administrator then can select either
that chassis to manage or any other chassis in the group.
The Cuda 12000 uses a proxy-based approach to communicate between the
host chassis — the chassis to which you are currently logged in — and other
chassis within the same group. The Java server on the management module
in the host chassis forwards network management messages that are
destined for other chassis to the appropriate chassis group member.
You can manage SNMPv3 resources (contexts and users) on the host chassis
only. In addition, you can manage hardware alarms/faults and user accounts
on the host chassis only. You cannot manage SNMPv3, hardware
alarms/faults, and user accounts by proxy.