Raritan Computer Home Security System 用户手册
Chapter 15: Advanced Administration
225
9. Select the checkboxes before the traps you want CC-SG to push to
your SNMP hosts: Under Trap Sources, a list of SNMP traps
grouped into two different categories: System Log traps, which
include notifications for the status of the CC unit itself, such as a
hard disk failure, and Application Log traps for notifications
generated by events in the CC application, such as modifications to
a user account. To enable traps by type, select the boxes marked
System Log and Application Log. Individual traps can be enabled or
disabled by selecting their checkboxes. Use the checkbox inside the
Selected column header to enable all traps, or deselect all
checkboxes. Refer to the MIB files for the list of SNMP traps that are
provided. See MIB Files for details.
grouped into two different categories: System Log traps, which
include notifications for the status of the CC unit itself, such as a
hard disk failure, and Application Log traps for notifications
generated by events in the CC application, such as modifications to
a user account. To enable traps by type, select the boxes marked
System Log and Application Log. Individual traps can be enabled or
disabled by selecting their checkboxes. Use the checkbox inside the
Selected column header to enable all traps, or deselect all
checkboxes. Refer to the MIB files for the list of SNMP traps that are
provided. See MIB Files for details.
10. Click Add to add this destination host to the list of configured hosts.
There is no limit to the number of managers that can be set in this
list.
list.
11. Click Update Trap Configuration to save your changes.
MIB Files
Because CC-SG pushes its own set of Raritan traps, you must update all
SNMP managers with a custom MIB file that contains Raritan SNMP trap
definitions. See
SNMP managers with a custom MIB file that contains Raritan SNMP trap
definitions. See
SNMP Traps
(on page 330). The custom MIB file can be
found on on the Raritan Support web site.
Configuring CC-SG Clusters
A CC-SG cluster uses two CC-SG nodes, one Primary node and one
Secondary node, for backup security in case of Primary node failure.
Both nodes share common data for active users and active connections,
and all status data is replicated between the two nodes.
Secondary node, for backup security in case of Primary node failure.
Both nodes share common data for active users and active connections,
and all status data is replicated between the two nodes.
Devices in a CC-SG cluster must be aware of the IP of the Primary CC-
SG node in order to be able to notify the Primary node of status change
events. If the Primary node fails, the Secondary node immediately
assumes all Primary node functionality. This requires initialization of the
CC-SG application and user sessions and all existing sessions
originating on the Primary CC-SG node will terminate. The devices
connected to the Primary node will recognize that the Primary node is
not responding and will respond to requests initiated by the Secondary
node.
SG node in order to be able to notify the Primary node of status change
events. If the Primary node fails, the Secondary node immediately
assumes all Primary node functionality. This requires initialization of the
CC-SG application and user sessions and all existing sessions
originating on the Primary CC-SG node will terminate. The devices
connected to the Primary node will recognize that the Primary node is
not responding and will respond to requests initiated by the Secondary
node.