Overview

Path monitoring

You can use the CPAM to monitor registered paths. When a network topology changes, such as a link metric or state change, the system evaluates whether the routes of any registered path are affected. If this is the case, new routes are recorded and CPAM clients are immediately informed. If there is no route for a monitored path as a result of a topology change, a record is logged.

When a monitored path is deleted, the log records for the path are also deleted. Deleted links previously used by the monitored path are not highlighted on the topology map. The CPAM stops monitoring paths when an endpoint router of the path is no longer seen by the CPAM.

The CPAM does not raise an alarm when a monitored path is modified. The initial path and each modified path are recorded and can be reviewed or highlighted on a topology map. The CPAM supports the following types of path monitoring:

• IP path monitoring

  Monitors the IP path between two system IP addresses

• LSP path monitoring

  Monitors the path (active, secondary, and primary) of an LSP

• P2MP LSP path monitoring

  Monitors the path (active, secondary, and primary) of a P2MP LSP

IP path monitoring

The CPAM supports unidirectional and bidirectional IP path monitoring within an IGP administrative domain. Bidirectional IP path monitors determine path divergence and the CPAM raises a self-clearing alarm when the two paths do not share the same set of IP links. If you create two unidirectional IP path monitors instead of a bidirectional path, the CPAM does not monitor path divergence.

You can use the synchronization manager to create unidirectional and bidirectional IP path monitors for PTP peers, and to navigate to and view IP path monitors. See the Synchronization management chapter in the NSP NFM-P Classic Management User Guide.

Multicast management and IP path monitoring

There is a correlation between IP path monitoring and a multicast tree. When you configure a multicast tree from a leaf to an RP, from a leaf to a multicast source, or from a multicast source to an RP (depending on the mode of operation—PIM-SM or PIM-SSM), all of the links must be PIM-enabled. If there is a failure on the path and the IP path switches to a new path, all of the links on the new path must also be PIM-enabled.

To monitor the health of the IP path between the following NEs, you can enable multicast monitoring on the IP path:

• IGMP leaf to RP

• IGMP leaf to source

• source to RP

If multicast monitoring is enabled, the CPAM monitors not only the IP path, but all of the upstream links (from the IGMP leaf to RP or source, or source to RP) to ensure that they are PIM-enabled. The CPAM raises an alarm if a link is not PIM-enabled.

Note: The PIM routers can use different routing tables for multicast, or use different policies for RPF interfaces. If the PIM routers use the unicast routing table without a policy, the multicast management of the IP path on the CPAM ensures that the multicast tree is successfully created and that it stays healthy.

You can view the segments of the route that have multicast enabled by viewing the Segments tab on an IP path record form. See To view IP path records for information about how to view IP path records.

See To monitor an IP network path for information about how to enable multicast monitoring.

LSP path monitoring

LSP path monitoring is similar to IP path monitoring. In addition to monitoring the dynamic LSP, the CPAM simultaneously monitors each path of the LSP. Bidirectional LSP path monitors determine path divergence and the CPAM raises a self-clearing alarm when the hops of the active path of the LSP do not match in both directions. If you create two unidirectional LSP path monitors instead of a bidirectional path, the CPAM does not monitor path divergence.

You can select the type of path that the CPAM monitors:

• active

• primary

• secondary with standby option

The CPAM records whether a bypass tunnel is used.

Note: The actual path may not always follow the provisioned path. For example, if fast reroute has occurred, the actual path uses one or more bypass tunnels.

When the LSP is operationally down, a record is created even if there is no actual route. Subsequent connection attempts by RSVP are not logged until the path becomes operational.

You can view historical LSP path monitor statistics when performance statistics collection is enabled in the NFM-P. A statistics collection event is logged after each polling interval. The statistics collection events are displayed on the Events tab of the LSP path monitor form. LSP path records are shown on the Path History tab.

Correlation of path records and routing events

To aid in troubleshooting and root cause analysis, the CPAM provides correlation and navigation from IP and LSP path records to routing events. In the context of path monitoring, routing events are of two types:

• Cause events

• IGP events

Cause events

Cause events are the LSAs that are generated when changes occur in the network. The CPAM records the following LSA types:

• Router LSAs (for OSPF)

• Network LSAs (for OSPF)

• Link State PDUs (for IS-IS)

• TE Link TLV (for GRE and MPLS service tunnels)

Cause event LSAs and PDUs are retrieved from the CPAA LSDB when protocol flags are enabled; see Chapter 4, Topology management for information about LSDB updates.

You can navigate from IP and LSP path records to cause events, and from cause events to path records. Viewing cause events correlated with path records allows network troubleshooting at a very granular level. See Stage 10 of Workflow for path and prefix monitoring for links to procedures.

IGP events

The CPAM analyzes cause event LSAs and produces IGP events that summarize changes in the network. The IGP event function reduces the need for manual examination of individual cause event LSAs. IGP events record the following change types for links:

• Added

• Flapped

• TE Metric changed

• TE Status changed

• Metric changed

• IPv6 Metric changed

The CPAM provides correlation of IP and LSP path records with IGP events. Tabs on the property forms for these records allow quick navigation from:

• IP and LSP path records to correlated IGP events

• IGP events to related IP or LSP path records

Correlation allows you to view the IGP event related to a particular path record, or the path records that result from an IGP event. You can also navigate to highlighted maps of the affected links.

Note: Nokia recommends that you enable BFD on the routing protocol to produce accurate correlation results. The accuracy of correlations also depends on the timing of records in the NFM-P. Some system configurations may not produce up-to-date correlations.

For S2L path monitors, correlation is not supported for IGP events.

BGP prefix monitoring

The CPAA monitors IPv4, IPv6, VPN IPv4, VPN IPv6, and EVPN prefixes in the BGP AS or confederation sub-AS to which it is assigned. The CPAA in the AS or sub-AS reports to the CPAM if one of the monitored routes is added or withdrawn. Neighboring routers send each other update messages to exchange routing information, such as withdrawn routes or preferred paths.

In addition, the CPAA monitors the next hops for each monitored route. A maximum of eight next hops is reported to the CPAM for every monitored route. The CPAA reports any next hop changes for a monitored route to the CPAM. You can retrieve and view this information using the CPAM.

You can configure monitored prefixes on the CPAM for each BGP AS or sub-AS via the GUI or the XML API. See To configure BGP monitored prefixes for information about how to configure monitored prefixes using the GUI.

If you configure threshold reaching alarms, the CPAM raises an alarm for all of the actively monitored routes in each BGP AS when the CPAM detects route flapping — routes that appear and disappear, or changing next hops. You can manually clear the alarms. The CPAA clears the alarms when the flapping stops. You can specify the flapping rate threshold within an interval for which the CPAM raises an alarm.

In addition, the CPAM raises the BGP Monitored Prefix Unreachable alarm when a BGP route to a monitored prefix is not found by the CPAA. You can suppress these alarms for each monitored BGP prefix. See To configure alarm thresholds for information about how to configure the alarm.

GNE support

The CPAM supports the limited management of GNEs. The CPAM support of GNEs requires the proper MIB support on GNEs.

Note: Standard MIBs support read-only mode for the path objects. LSPs or paths can not be configured from the NFM-P.

The NFM-P mediation engine supports standard MPLS MIBs. The GNEs managed by the NFM-P using standard MIBs must use attributes, IDs and traps in a specific manner to ensure proper operation. Otherwise, LSP objects may be represented incorrectly in the NFM-P.

See Appendix A, CPAM MIB support for GNEs for information about MIB support. See “To prepare a GNE for NFM-P management” in the NSP NFM-P Classic Management User Guide for information about how to add a routing MIB to a GNE profile.

© 2024 Nokia. Nokia Confidential Information

Use subject to agreed restrictions on disclosure and use.