OSS applications that are integrated with the CPAM can be used to monitor IGP paths between any two routers or BGP prefixes available to the CPAM. 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. In this case, new routes are recorded and the OSS clients are immediately informed. If there is no route for a monitored path as a result of a topology change, a record is logged.

The CPAM supports the following types of path monitoring:

• IP network path monitoring

  Monitors the IP forwarding path between two system IP addresses and supports both unidirectional and bidirectional IP path monitoring within a single IGP administrative domain.

• LSP path monitoring

  Monitors the path (active, secondary, and primary) of a specified LSP, and supports both unidirectional and bidirectional LSP path monitoring.

• P2MP LSP path monitoring

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

• BGP monitored prefix

  Monitors BGP IPv4, IPv6, VPN-IPv4, and VPN-IPv6 prefixes visible to CPAM.

See “Path and prefix monitoring” the NSP NFM-P Control Plane Assurance Manager User Guide for more information about path monitoring.

The following workflows describe how to configure and view IP and LSP path monitors.

For an IP path monitor:

1. Create an IP path monitor between two routers. The monitor can be a unidirectional or bidirectional monitor.

2. Monitor the IP network path.

3. View any changes on the path.

For a LSP path monitor:

1. Create a LSP path monitor from an NFM-P managed dynamic LSP. It can be a unidirectional or bidirectional monitor.

2. Monitor the LSP path.

3. View any changes on the path.

For a BGP monitored prefix:

1. Create a BGP monitored prefix for a supported BGP prefix.

2. Monitor the BGP prefix.

3. View any change of BGP prefix status.

The monpath package is used to monitor changes to the paths of IP routes, LSPs, and the topology package used to monitor BGP prefixes. The changes are recorded, as they occur, by CPAM IP and LSP path monitors, and BGP monitored prefixes. The following table shows the classes for configuring and retrieving monitored objects.

Table 21-6: Monitor objects

The XML API supports the creation, deletion, and modification of IP and LSP path monitors, and BGP monitored prefixes. The following example shows the minimum XML parameter tags required to develop an XML request to create a unidirectional IP path monitor.

The generic.GenericObject.configureChildInstance method is used to create an IP path monitor. The request response returns the <objectFullName> attribute to identify the new IP path monitor.

IP path monitor creation parameters

• method—generic.GenericObject.configureChildInstance

• distinguishedName—monitored-path-mgr. The FDN can be determined by looking at the Parent Hierarchy of the class to be created in the XML API Reference. In this case, it is the monpath.MonitoredPathManager class.

• childConfigInfo—creates and configures the following parameters:

  • IP path monitor object - monpath.MonitoredIpPath

  • actionMask - specifies the create operation

  • <source> - source address of the monitored path

  • <dest> - destination address of the monitored path

  • <administrativeState> - enables or disables the path monitoring

Figure 21-15: Unidirectional IP path monitor creation request example

<generic.GenericObject.configureChildInstance xmlns="xmlapi_1.0">   <deployer>immediate</deployer>   <distinguishedName>monitored-path-mgr</distinguishedName>   <childConfigInfo>      <monpath.MonitoredIpPath>         <actionMask>            <bit>create</bit>         </actionMask>         <source>198.51.100.36</source>         <dest>198.51.100.35</dest>         <administrativeState>up</administrativeState>      </monpath.MonitoredIpPath>   </childConfigInfo></generic.GenericObject.configureChildInstance>

LSP path monitors can also be created using the monpath.MonitoredPathManager.createMonitoredPath method. This method can be used to create multiple monitored paths from the passed-in LSPs or service tunnels.

LSP path monitor creation using createMonitoredPath method

• method—monpath.MonitoredPathManager.createMonitoredPath

• <sourceObjectNameSet>—the set of LSP or service tunnel object pointers to create monitored LSP paths from.

  • <pointer> - FDN of a dynamic LSP or service tunnel - add one for each LSP or service tunnel

• <isBidirectional>—whether to create bidirectional monitored paths - true or false

• <pathType>—sets the path types (active, primary, secondary). Set all applicable bits.

  • <bit> - monpath.PathTypeBitMask bitmask value

Figure 21-16: Multiple LSP path monitor creation request example

<monpath.MonitoredPathManager.createMonitoredPath>   <deployer>immediate</deployer>   <sourceObjectNameSet>      <pointer>lsp:from-198.51.100.35-id-1</pointer>      <pointer>lsp:from-198.51.100.32-id-4</pointer>   </sourceObjectNameSet>   <isBidirectional>false</isBidirectional>    <pathType>      <bit>active</bit>   </pathType></monpath.MonitoredPathManager.createMonitoredPath>

Path monitoring can be manually triggered by using the captureCurrentPath method. The method captures the state of the path at the moment the method is executed.

Each of the classes that can be used to create an IP or LSP path monitor has its own captureCurrentPath method. For example, the captureCurrentPath method for a unidirectional IP path monitor is under the monpath.MonitoredIpPath called monpath.MonitoredIpPath.captureCurrentPath.

Capture current path method

• method—monpath.MonitoredIpPath.captureCurrentPath

• instanceFullName—monitored-path-mgr:ip-path-src-${sourceType}-${source}-${sourceLen}-dest-${destType}-${dest}-${destLen}. The FDN can be determined by looking at the Parent Hierarchy of the class to be created in the XML API Reference. In this case, it is the monpath.MonitoredIpPath class.

Figure 21-17: Current unidirection IP path capture request example

<monpath.MonitoredIpPath.captureCurrentPath xmlns="xmlapi_1.0">   <deployer>immediate</deployer>   <instanceFullName>monitored-path-mgr:ip-path-src-ipv4-198.51.100.36-32-dest-ipv4-198.51.100.35-32</instanceFullName></monpath.MonitoredIpPath.captureCurrentPath>

See the XML API Reference for descriptions of the input parameters.

The find or findToFile method, along with the appropriate class for path record and segment specified in Table 21-6, Monitor objects , and a filter, can be used to retrieve path monitor data.

Retrieving path record data

• method—find

• fullClassName—the class from where data is to be retrieved. For Figure 21-18, IP path record retrieval request example , the class is the monpath.IpPathRecord class.

• filter—sets a filter to only return IP path record objects that satisfy the filter criteria

  • The filter criteria is to look for source of 198.51.100.36, and destination of 198.51.100.37.

The following figure shows an example of a request to find IP path records that match a filter.

Figure 21-18: IP path record retrieval request example

<find xmlns="xmlapi_1.0">   <fullClassName>monpath.IpPathRecord</fullClassName>   <filter>      <and>                 <equal name="source" value="198.51.100.36"/>         <equal name="dest" value="198.51.100.37"/>      </and>   </filter></find>

See Chapter 13, Inventory management for more information about using the find and findToFile method and filters.

The following figure shows an example XML request to create a BGP monitored IPv4 prefix.

Figure 21-19: BGP monitored IPv4 prefix creation request example

<generic.GenericObject.configureChildInstance>   <deployer>immediate</deployer>      <synchronousDeploy>true</synchronousDeploy>      <deployRetries>1</deployRetries>      <clearOnDeployFailure>true</clearOnDeployFailure>      <distinguishedName>tpgy-mgr</distinguishedName>      <childConfigInfo>        <topology.BgpMonitoredPrefix>         <actionMask>           <bit>create</bit>         </actionMask>         <bgpASPointer>tpgy-mgr:AS-50:AS-65050</bgpASPointer>         <prefRd></prefRd>         <displayedName></displayedName>         <description></description>         <alarmSuppress>           <bit>asPath</bit>           <bit>redLoss</bit>           <bit>unreachable</bit>         </alarmSuppress>         <prefAddr>2.0.0.0</prefAddr>         <asPathLenThreshold>1</asPathLenThreshold>         <prefAddrType>ipv4</prefAddrType>         <prefLen>32</prefLen>         <alarmThreOverride>           <bit>asPath</bit>           <bit>redLoss</bit>         </alarmThreOverride>         <redLossThreshold>1</redLossThreshold>         <administrativeState>up</administrativeState>         <prefType>ipv4</prefType>         <rdType>none</rdType>        </topology.BgpMonitoredPrefix>      </childConfigInfo></generic.GenericObject.configureChildInstance>

The following xml tags describe the inputs to this request:

• distinguishedName - CPAM AS Object FDN

• bgpASPointer - CPAM AS object FDN

• prefRD - route-distinguisher monitored Prefix for VPN-IPv4, VPN-IPv6

• displayedName - displayed name of monitored prefix

• description - description of monitored prefix

• prefAddr - IP address of the monitored Prefix

• prefAddrType - Prefix address type ipv4, ipv6

• prefLen - Prefix length

• prefType - BGP prefix type ipv4,ipv6,vpnIpv4 or vpnIpv6

• administrativeState - up or down

• rdType - BGP prefix route distinguisher type none (IPv4,IPv6) or type0,type1 or type2 for VPN-IPv4, VPN-IPv6

• alarmSupress (optional) - if BGP monitored Prefix Alarms are configured, the user can supress the BGP monitored prefix alarms specified by the bit flag:

  • aspath - supress BGP monitored prefix alarm topology.BgpAsPathLenPerMonPrefThresholdReached

  • redloss - supress BGP monitored prefix alarm topology.BgpMonPrefRedundancyLossThresholdReached

  • unreachable - supress BGP monitored prefix alarm topology.BgpMonPrefixUnreachable

• alarmThreOverride (optional) - for given BGP monitored Prefix, override the following alarms by set by bit flags of value:

  • asPath - override alarm topology.BgpAsPathLenPerMonPrefThresholdReached

  • redLoss - override alarm topology.BgpMonPrefRedundancyLossThresholdReached

• redLossThreshold (optional) - if the alarmThreOverride with bit flag redLoss is set, the user can specify the threshold override value for alarm topology.BgpMonPrefRedundancyLossThresholdReached

• asPathLenThreshold (optional) - if the alarmThreOverride with bit flag asPath is set, the user can specify the threshold override value for alarm topology.BgpAsPathLenPerMonPrefThresholdReached

If the user wants to manually capture a monitored prefix status record, the following XML request can be used:

Figure 21-20: Manually capture a monitored prefix status record request example

<topology.BgpMonitoredPrefix.captureCurrentPrefix xmlns="xmlapi_1.0">    <deployer>immediate</deployer><!--Type:deployer-->    <synchronousDeploy>true</synchronousDeploy><!--Type:synchronousDeploy-->    <clearOnDeployFailure>true</clearOnDeployFailure><!--Type:clearOnDeployFailure-->    <deployRetries>1</deployRetries><!--Type:deployRetries-->    <deployRetryInterval>60</deployRetryInterval><!--Type:deployRetryInterval-->    <taskDescription></taskDescription><!--Type:taskDescription-->    <instanceFullName>tpgy-mgr:AS-50:AS-65050:type-ipv4-rdtype-none-rd--addr-2.0.0.0-len-32</instanceFullName><!--Type:instanceFullName--></topology.BgpMonitoredPrefix.captureCurrentPrefix>

• instanceFullName - monitored Prefix FDN