How to model and mange remote sites in Spectrum

Document ID : KB000045075
Last Modified Date : 04/12/2018
Show Technical Document Details
Introduction:

I have many remote sites that connect through a central site but do not have access to all of the devices in the central site. So in my modeling, I have several different container models containing models that are not connected to any other models in the database.

458384_1.png

 

This causes Spectrum to assert a suppressed condition on all the models within the container when contact is lost to all models within the container. 

458384_2.png 

 

I am looking for recommendations on how to configure Spectrum to better alarm in this instance and for other modeling scenarios.

 

 

Instructions:

INSTRUCTIONS: For the assertion of a suppressed condition on all the models within the container, you can follow the instructions outlined in knowledge document TEC518718 - How to alarm on a model in a Fault Domain when contact is lost to all models in the Fault Domain. By setting the "Unresolved Fault Alarm Disposition" to "Device In Fault Domain" and increasing the value of the Criticality attribute id 0x1290c of a model within the Fault Domain, should Spectrum lose contact with all the models within the Fault Domain, Spectrum will assert the "UNRESOLVED FAULT DETECTED" alarm on the model within the Fault Domain instead of the Fault Isolation model.

 458384_3.png

 

If there are many different remote sites, a major outage could cause many different critical alarms. One way to avoid this is to use an intermediate model such as a Fanout to connect the different remote sites to a central location. This is done by manually creating the Fanout model and connecting it to one of the interfaces of a model within the remote site. 

458384_4.png

 

When using the Fanout, when contact is lost to all the models within the remote site, the models will be suppressed and an alarm asserted on the Fanout:

458384_5.png

Note: If you have 50 or more connections to a single Fanout model, consider changing the model to a SharedMediaLink. The SharedMediaLinks must be modeled manually. These models can provide more control over fault management behavior when multiple connections are monitored. Unlike a Fanout model, SharedMediaLinks provide configurable thresholds for handling downstream connections that report problems. For example, a Fanout model reports a problem only when all downstream connections are down. However, a SharedMediaLink can report the problem sooner, as when 60 percent of the downstream connections are down.

458384_6.png

 

To use the SharedMedialLink model, you would model it the same as a Fanout. Manually create the ShareMediaLink model and connecting it to one of the interfaces of a model within the remote site. 

458384_7.png

 

When using the SharedMediaLink, when contact is lost to all the models within the remote site, a Critical alarm is asserted on the model connected to the SharedMediaLink model. Then, depending on the threshold setting on the SharedMediaLink model, an alarm may be asserted there as well:

458384_8.png