Configure Cross-Landscape Fault Correlation

Contents
casp1032
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
proxy
model 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 Spectrum
suspends 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 section.
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:
  1. Select the device model to designate as a proxy model.
  2. Click the Information tab, and expand the
    DX NetOps Spectrum
    Modeling Information subview.
  3. 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:
spec--crosslandscape_proxy_example_SCR
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:
spec--crosslandscape_proxy_OTH
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:
spec--crosslandscape_proxy_fault_OTH
Configuring Port Status Monitoring
DX NetOps Spectrum
provides the following methods of monitoring the status of ports:
  • Link Traps
    Link 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.
  • PollPortStatus
    The PollPortStatus feature lets you poll the status of a port even if its connectivity is not modeled in
    DX NetOps Spectrum
    .
  • Live Pipes
    Live Pipes let you turn on port status monitoring for individual links. This is a more reliable monitoring method than traps because
    DX NetOps Spectrum
    will 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 Monitoring
    WA_Link models automatically enable a live pipe for any connected ports.
  • NetworkLinkType
    DX NetOps Spectrum
    automatically 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.
    For more information about the NetworkLinkType attribute and management policies in general, see the section.
    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
    If the connectivity of the port is not modeled, NetworkLinkType will be set to Unknown Link. When the connectivity of the port is modeled, the value of NetworkLinkType is maintained as described in the following table:
Connection
Attribute Value
Link Type
Router > Router
1
Router
Router > Switch Router
1
Router
Router > Switch
1
Router
Router > Hub
1
Router
Router > Workstation Server
1
Router
Switch Router > Switch Router
2
Switch
Switch Router > Switch
2
Switch
Switch Router > Hub
3
Shared Access
Switch Router > Workstation Server
4
End Station
Switch > Switch
2
Switch
Switch > Hub
3
Shared Access
Switch > Workstation Server
4
End Station
Hub > Hub
3
Shared Access
Hub > Workstation Server
4
End Station
Any port connected to a WA_Link model
5
Wide Area
Any backplane connecting inside a hardware device
6
Internal Link
EVPN Discovery is run and Provider_Clouds are created
8
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 in
    DX NetOps Spectrum
    and 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.
Event Description
Event ID
Alarm Description
Alarm ID
Port Condition Color
Port status good
0x10d10
N/A
N/A
Green
Port status bad
0x10d11
BAD LINK
0x1040a
Red
Port status disabled
0x10d12
LINK DISABLED
0x1040b
Brown
Port status unknown
0x10d13
LINK STATUS UNKNOWN
0x1040e
Gray
Port status unreachable
0x10d14
UNREACHABLE LINK
0x1040c
Gray
Port status initial
0x10d15
N/A
N/A
Blue
Port lower layer down
0x10d16
BAD LINK, BUT ALARM WAS SUPPRESSED
0x1040f
Gray
Port up, but linked with down port
0x10d17
LINK MAY NOT BE UP
0x10410
Gray
Port connected to down port or device
0x10d18
PORT ALARM SUPPRESSED
0x10411
Gray
Port status bad, but connected to WA_Link whose LinkFaultDisposition is LinkOnly
0x10d2d
PORT ALARM SUPPRESSED
0x10d2d
Gray
 
Link Traps
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.
When
DX NetOps Spectrum
receives 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 Spectrum
generates 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 Spectrum
sets the OutstandingLinkDownTrap attribute on the port to TRUE. This will cause
DX NetOps Spectrum
to poll the status of the port regardless of the port status polling criteria. When
DX NetOps Spectrum
receives 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 Spectrum
has 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 Spectrum
handles link traps:
  • AlarmOnLinkDownIfTypes
    This 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
  • AlarmOnLinkDownTrap
    This 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)
    ID:
    0x11fc2
  • AssertLinkDownAlarm
    This attribute is used to determine if the yellow alarm should be generated on the device model. It is read from the port model for which
    DX NetOps Spectrum
    received 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 Spectrum
management 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.
PollPortStatus Feature
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
SpectroSERVER
.
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
Results
FALSE
FALSE
Port status is not polled for any port on device
TRUE
FALSE
Port status is not polled for this port on device
FALSE
TRUE
Port status is not polled for this port on device
TRUE
TRUE
Port status is polled for this port on device
DX NetOps Spectrum
watches 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