Configure Cross-Landscape Fault Correlation
In a distributed
SpectroSERVER(DSS) environment, a network administrator may need to model a router from a local landscape in a remote landscape for its connections to participate in fault isolation for the remote landscape. This
proxymodel doesn’t need to participate in alarm generation in the remote landscape because it already does so in the local landscape where it is modeled “normally.” It is in the local landscape that alarms for the router are tracked and trouble tickets are created.
In such a scenario, Cross-Landscape Fault Correlation can prevent multiple red alarms for the same outage. With the Enable Event Creation attribute set to FALSE in the proxy model’s Fault Management subview,
DX NetOps Spectrumsuspends the creation of events for the model (and any component models such as boards or ports). This effectively disables alarms for the model, but unlike maintenance mode, SNMP communication with the proxy model continues, and so too does its participation in fault isolation.
For more information about distributed network management, see the
Designate a Model as a Proxy Model
You can designate a device model as a proxy model from the Information tab of the selected device model. Setting a device model up as a proxy model disables event creation for that model.
When you have multiple proxy models in a Global Collection topology, you can collapse them to a single icon, merging all connections.
Follow these steps:
- Select the device model to designate as a proxy model.
- Click the Information tab, and expand theDX NetOps SpectrumModeling Information subview.
- Locate the ‘Is a Proxy Model’ setting, click ‘set,’ and select Yes.Event creation is disabled for this model. The model now serves as a proxy model.
Cross-Landscape Fault Correlation Example
The following diagram provides an example of a network with multiple landscapes:
Landscape A, the local landscape, contains core routers, including Router R. Landscape B, the remote landscape, contains customer routers with the core Router R modeled a second time, this time as a proxy, as shown in the following diagram. This proxy model has its IsEventCreationEnabled attribute set to No. The device is being polled, but will not generate events or alarms.
Router R in Landscapes A and B:
If Router R goes down, as shown in the following diagram, Landscape B loses contact with the proxy and customer routers. However, only one red alarm is generated, in Landscape A. The proxy router stays green in Landscape B, where the alarms are suppressed because the proxy model’s IsEventCreationEnabled attribute is set to No.
Alarm with Cross-Landscape Fault Correlation:
Configuring Port Status Monitoring
DX NetOps Spectrumprovides the following methods of monitoring the status of ports:
- Link TrapsLink traps allow you to monitor the status of ports without the cost of polling. However, traps are not always the most reliable notification mechanism of port status.
- PollPortStatusThe PollPortStatus feature lets you poll the status of a port even if its connectivity is not modeled inDX NetOps Spectrum.
- Live PipesLive Pipes let you turn on port status monitoring for individual links. This is a more reliable monitoring method than traps becauseDX NetOps Spectrumwill periodically poll the status of the link (with an increased cost in performance). In addition, Live Pipes let you graphically verify which links are being monitored.
- WA_Link Port MonitoringWA_Link models automatically enable a live pipe for any connected ports.
- NetworkLinkTypeDX NetOps Spectrumautomatically maintains the port-level attribute NetworkLinkType based on the model class of the two connected devices. The attribute lets you set up management policies based on the type of link a port is involved in.The possible values for NetworkLinkType include the following:
- 0 = No Link
- 1 = Router Link
- 2 = Switch Link
- 3 = Shared Access Link
- 4 = End Station Link
- 5 = Wide Area Link
- 6 = Internal Link
- 7 = Unknown Link
- 8 = Network Cloud Link
Router > Router
Router > Switch Router
Router > Switch
Router > Hub
Router > Workstation Server
Switch Router > Switch Router
Switch Router > Switch
Switch Router > Hub
Switch Router > Workstation Server
Switch > Switch
Switch > Hub
Switch > Workstation Server
Hub > Hub
Hub > Workstation Server
Any port connected to a WA_Link model
Any backplane connecting inside a hardware device
EVPN Discovery is run and Provider_Clouds are created
Network Cloud Link
Port Status Polling Criteria
In general, the status of a port is polled when the following criteria are met:
- The PollingStatus (0x1154f) of the port model must be TRUE.
- The Polling_Interval (0x10071) of the port model must be non-zero.
- The PollingStatus of the port’s device model must be TRUE.
- Neither the port model nor the port’s device model can be in maintenance mode; the isManaged (0x1295d) attribute for both must be set to TRUE.
If this criteria is met, port polling occurs with a frequency equal to the Polling_Interval setting.
However, either of the following two conditions override the default polling frequency:
- The port has been down since it was modeled inDX NetOps Spectrumand the Port Always Down Alarm Suppression attribute is set to Enabled.If the Port Always Down Alarm Suppression attribute is set to Disabled, the port will be polled as described above.
- The port is administratively down (that is, ifAdminStatus attribute is set to Down).
If these criteria are met, the polling frequency is reduced to once per hour (every 3600 seconds). Plus, all red alarms on the down ports are suppressed, and a gray condition is asserted. Administratively down ports remain brown.
Port Status Events and Alarms
The port status monitoring engine uses the events and alarms listed in the following table to notify you of a change in status.
Port Condition Color
Port status good
Port status bad
Port status disabled
Port status unknown
LINK STATUS UNKNOWN
Port status unreachable
Port status initial
Port lower layer down
BAD LINK, BUT ALARM WAS SUPPRESSED
Port up, but linked with down port
LINK MAY NOT BE UP
Port connected to down port or device
PORT ALARM SUPPRESSED
Port status bad, but connected to WA_Link whose LinkFaultDisposition is LinkOnly
PORT ALARM SUPPRESSED
Traps provide a means for network devices to let a management system know that a significant event has occurred on the network. Link Down and Link Up traps are perhaps the most important traps when it comes to port status monitoring. These traps tell the management system that a port has either become inoperable, or has come back up.
DX NetOps Spectrumreceives a Link Down trap, it polls the status of the corresponding port once to verify its status and generates one of the events and alarms listed in Port Status Events and Alarms on the affected port.
DX NetOps Spectrumgenerates a yellow alarm on the device model to allow easy access to vendor-specific trap data, however it no longer generates the trap-specific events and alarms on the affected port model.
Once a Link Down trap is received,
DX NetOps Spectrumsets the OutstandingLinkDownTrap attribute on the port to TRUE. This will cause
DX NetOps Spectrumto poll the status of the port regardless of the port status polling criteria. When
DX NetOps Spectrumreceives a Link Up trap for the port, or when the port’s status is determined to be up based on a poll, the value of the OutstandingLinkDownTrap attribute is set to FALSE and polling will take place based on the value of the port status polling criteria. For more information about when a port is polled, see Port Status Polling Criteria.
When all of the ports for which
DX NetOps Spectrumhas received a Link Down trap are back up, the yellow alarm on the device will be cleared.
You can use the following attributes to control how
DX NetOps Spectrumhandles link traps:
- AlarmOnLinkDownIfTypesThis attribute contains a mapping of ifType values to a value which determines how to handle the trap for that particular ifType and model type (0 for never, 1 for always, and 2 for check admin). This can be customized in the MTE on a per-model type basis. When a port model is created, its AlarmOnLinkDownTrap (0x11fc2) attribute is automatically populated with the value which corresponds to its particular ifType.ID:0x1290f
- AlarmOnLinkDownTrapThis attribute sets the alarm generation behavior for receipt of a LINK DOWN Trap Event. Possible settings are:
- Never (0) = Do not generate an alarm upon receipt of LINK DOWN trap
- Check Status (1) = Generate an alarm based on the current Admin Status (UP = Generate a Red alarm, otherwise generate a Brown alarm)
- AssertLinkDownAlarmThis attribute is used to determine if the yellow alarm should be generated on the device model. It is read from the port model for whichDX NetOps Spectrumreceived the trap. This attribute is available from the port model’s Attributes tab.ID:0x12957
Interface Trap Configuration
For many device models, you can configure the processing of link down traps received for individual port models through the port model’s Interfaces tab, Component Detail view, Attributes tab. Here you can access the attributes that let you suppress link down alarms for the selected port model or its parent device model. Consult the
DX NetOps Spectrummanagement module section for the type of device you are interested in to see if that module supports such trap configuration.
You can also use Locater search to select a set of port models and then the Attribute Editor to update in bulk.
The PollPortStatus feature lets you monitor the status of a port even if the port’s connectivity is not modeled. The PollPortStatus attribute exists for both Device and Port models with a different attribute ID for each of the two model types. This lets you enable and disable port status polling at the device or port level. By default, PollPortStatus is set to TRUE at the device level and FALSE at the port level.
To reduce network traffic, SNMP reads for polled ports on the same device are grouped together into larger SNMP requests. This provides performance benefits that are most noticeable when many ports are polled by this method in a single
Utilizing PollPortStatus to Watch a Connected Port’s Status
The PollPortStatus attribute at the device level (0x12809) controls port status polling on a per-device basis. If TRUE, polling is enabled for that device. If FALSE, no ports will be polled, even if a port model’s PollPortStatus attribute is TRUE. When changed to FALSE, alarms will be cleared for any port which is not involved in a live pipe.
The PollPortStatus attribute at the port level (0x1280a) controls polling for each port model. If this attribute is set to TRUE (and PollPortStatus for the device is also set to TRUE), the status of the port will be polled, and alarms will be generated if needed. When changed to FALSE, any alarm on the port will be cleared. The following table shows that a port’s status will be polled only if PollPortStatus is TRUE for both a given port model and its device model.
Device Model’s PollPortStatus Value
Port Model’s PollPortStatus Value
Port status is not polled for any port on device
Port status is not polled for this port on device
Port status is not polled for this port on device
Port status is polled for this port on device
DX NetOps Spectrumwatches the polling interval to determine when to poll port status. When a port is polled, the port’s status is determined and an appropriate alarm is generated (RED, BROWN, or GRAY) if necessary.
If a BAD LINK alarm is generated on a port (alarm code 0x1040a), and later polling on that port is disabled by changing the value of PollPortStatus to FALSE and disabling Live Pipes, an event will be generated to automatically clear the BAD LINK alarm.
The PollPortStatus attribute can be set to TRUE while the Live Pipes functionality is enabled. This will not cause redundant network traffic.
Enabling Port Status Polling
You can enable port status polling for all future models of a given type using the Model Type Editor (MTE), or on a current, per-model basis using the Command Line Interface (CLI). For example, use the MTE to set PollPortStatus to TRUE for both device and port model types. Then, when polled, interface models will generate appropriate alarms when needed. PollPortStatus can also be set at both the device and port level using the Global Attribute Editor.
For information about using the CLI to enable or disable PollPortStatus for a single model, see the
Command Line Interface section.