# Appendix F

| # Status Propagation

> This appendix covers the following topics:

- Example Topology Hierarchy--page 635
- Missed SNMP Traps--page 638

> This appendix provides an example topology hierarchy configuration to demonstrate how status changes are propagated from the Sun Management Center agent to the Topology agent and Sun Management Center console.

> > Note - The Domain Alarms at the top of the Sun Management Center console should show the count of host entities in alarm throughout the topology hierarchy. The count does not include the cumulative alarms within each host.

## Example Topology Hierarchy

> The following figure illustrates an example topology consisting of the following domains, groups, and entities:

- Domain A
- Child Group B
- Host entities C and D
- Modules E and F residing in Host C and modules G and H in Host D.

> In addition, there is a console viewing Domain A and there are no current alarms. Thus, the total alarm counts are zero in the console.

> FIGURE F-1 Example Topology Hierarchy

> The following sections present example events or scenarios:

- Event 1: Node in Module E on Host C Goes into Error (Red)
- Event 2: Node in Module G on Host D Goes into Warning (Amber)
- Event 3: Node in Module F on Host C Goes into Warning (Amber)
- Event 4: Another Node in Module E on Host C Goes into Warning (Amber)

### Event 1: Node in Module E on Host C Goes into Error (Red)

- A status trap indicating a `status change for module E on host C' is generated.
- Since the error in module E is the most severe alarm on host C, the overall status of host C changes, causing another status trap indicating a status change for
  host C.
- Group B repolls host C, since the status trap for host C correlates with an existing SNMP job of group B.
- Since the host C in error is the most serious in group B, the overall status of group B is now in error as well. This generates a status trap indicating a status change for group B.
- A console viewing Topology group B would display the error immediately since this last status trap from group B would trigger a repoll of the group B and a subsequent screen update. Also, the host C icon gets a red circle at this point. The total count at the top of the screen still shows 0.
- A status trap for group B also triggers a repoll of domain A since it correlates with an existing SNMP job. Domain A immediately repolls group B for its current Status and child host alarm counts.
- The group B error alarm is the most severe alarm condition in domain A. This causes domain A to generate a status trap indicating a status change for domain A.
- If the console was viewing the top level of domain A, this status trap triggers a repoll of the domain A status, and thereby causes a red circle to appear on the group B icon in the display.
- The domain counts on the Console screen are triggered by the domain A status trap, to repoll domain A for the current alarm counts. The screen updates, showing the error count as 1.

> All of the above happens within a few seconds, since it is all trap based.

### Event 2: Node in Module G on Host D Goes into Warning (Amber)

> Assume this second event takes place after the first. This alarm is not as severe as the initial alarm currently in effect on host C.

- Status trap is generated indicating a status change for module G on host D.
- Since this is the most severe alarm condition on host D, the overall status of host D is warning. Another status trap indicating a status change for host D is generated.
- Group B detects a status change on host D and immediately repolls host D for its current status.
- The warning on host D is less severe than the error on host C, so the overall status of group B does not change (still is equal to the host C error). Nonetheless, group B generates a status trap indicating a "status change for group B". This trap is issued to inform higher topology layers about the change in child host D in group B.
- A console viewing group B would display the host D icon to be amber (warning) since this last status trap from group B would trigger a repoll and screen update. The total warning count at top of screen still shows 1 error (from host C), but 0 warnings (host D warning count not propagated up yet).
- Domain A detects the status trap for the group B and repolls group B for its current status and counts.
- Although the status of domain A's children have changed (group B was error before, and is still in error), domain A recognizes that the total child host count has changed: before there was one error, now there is one error and one warning. Accordingly, domain A generates a status trap indicating a status change in domain A. This trap will trigger a repoll and update of the Domain Counts on the Console Screen.

### Event 3: Node in Module F on Host C Goes into Warning (Amber)

> Assume this third event takes place after the others. This is a second event on host C. This alarm is only a warning and is less severe than the previous alarm on host C, which was an error. This new alarm is in a "different" module from the previous host C alarm.

- Status trap indicating a status change for module F on host C is generated.
- This is not the most serious condition on host C, but host C generates a status trap anyway, to indicate to upper layers that the status of module F changed (because this new alarm is in a different module, and module F was not in alarm before).
- Group B detects the status trap from host C and repolls host C for its current status.
- Group B notes that the overall status of host C has not changed, so group B does not need to generate any new traps (no change in child counts or status for group B).

### Event 4: Another Node in Module E on Host C Goes into Warning (Amber)

> Assume this fourth event takes place after the others. This one is a warning in another node in module E (there is already an error on this module from one of the previous events).

- Status trap issued indicating status change for a node in module E on host C.
- This is not the most severe alarm condition on module E on host C (an earlier error alarm condition was detected on another node). The overall status of host C Is unchanged and no new status trap is issued.
- No counts or status need to be updated anywhere in the topology.

## Missed SNMP Traps

> The delivery of SNMP traps is not guaranteed. If a status change trap is missed, then status and counts will not be updated immediately. However, this will correct itself on the next poll (generally less than five minutes).

Copyright © 2000 Sun Microsystems, Inc. All Rights Reserved.