How to model and manage remote sites in Spectrum
search cancel

How to model and manage remote sites in Spectrum

book

Article ID: 45075

calendar_today

Updated On:

Products

CA Spectrum DX NetOps

Issue/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.

 

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. 

 

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

Environment

Release: All Supported Releases
Component: SPCDIS - Discovery and Modeling

Resolution

INSTRUCTIONS: For the assertion of a suppressed condition on all the models within the container, you can follow the instructions outlined in knowledge document KB 51741 - How to alarm on a model in a Spectrum Fault Domain when contact is lost to all models in the Spectrum 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.


 

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. 



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:

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.

 

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. 


 

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: