Topology and checkpoint management

Overview

After the CPAM is commissioned and the proper IGP administrative domain, or BGP AS, or both, are assigned to the 7701 CPAAs and the 7701 CPAAs are up, IGP topologies are automatically populated in the CPAM.

Multiple topologies

The CPAM allows OSS applications to retrieve information about the following network protocol topologies:

See “Topology management” in the NSP NFM-P Control Plane Assurance Manager User Guide for more information about the supported topologies.

The XML API provides a read-only interface for topology objects, such as areas, routers, links, networks, and baselines. The JMS interface notifies the XML API of any changes to the topology model, including baselines. See Chapter 4, Event monitoring using JMS for information about how to connect and subscribe to JMS.

The CPAM topology package is used to manage routing topology objects and routing alarms. The CPAM supports IS-IS, OSPF, OSPFv3, and BGP.

OSPF, OSPFv3, and IS-IS topologies include information about routers, subnet objects, links, OSPF/OSPFv3 areas, IS-IS levels, and LSDB updates. The IGP topology includes information about routers, protocols for both OSPF, OSPFv3, and IS-IS, and information about IGP links. The following table shows the routing topology objects for IS-IS, OSPF, OSPFv3, and IGP.

Table 21-2: OSPF, IS-IS, and IGP routing topology objects

Object

Package and class

OSPF and OSPFv3

Area

topology.Area

Area Link

topology.OspfLink

Router

topology.Router

Area Subnet

topology.Subnet

IS-IS

Area

topology.Area

Domain Link

topology.IsisLink

Router

topology.Router

Domain Subnet

topology.IsisSubnet

IGP

Link

topology.IgpLink

Router

topology.Router

The find or findToFile method, along with the appropriate class specified in Table 21-2, OSPF, IS-IS, and IGP routing topology objects , and a filter, can be used to retrieve topology information.

A real-time topology object shares the same XML API class as a checkpointed data object; therefore, in the find or findToFile method filter, you need the following to distinguish real-time data from checkpointed data.

For real-time data:

<equal name='isCheckpointObject' value='false'/>

For checkpointed data:

<equal name='isCheckpointObject' value='true'/>

Retrieving IGP topology data

Figure 21-6: find request example, IGP links
<find xmlns="xmlapi_1.0">
   <fullClassName>topology.IgpLink</fullClassName>
   <filter>
      <and>        
         <equal name="isCheckpointObject" value="false"/>
         <equal name="asName" value="igp0"/>
         <equal name="routerIdStr" value="198.51.100.57"/>
      </and>
   </filter>
</find>

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

The MPLS topology includes information about IGP links, MPLS, RSVP, and LDP interfaces for routers.

The BGP topology includes BGP route information from a 7701 CPAA that monitors a BGP AS and maintains a BGP RIB. The 7701 CPAA supports the following BGP configurations:

Table 21-3: BGP topology objects

Package and class

Description

topology.Asn

AS number in BGP AS path attribute

topology.AsnLink

BGP ASN link between two autonomous systems

topology.BgpOriginatedAs

BGP-originated autonomous system number

topology.BgpRibInfo

BGP RIB-IN info

topology.BgpRibInfoValue

BGP RIB info value

topology.BgpRoutesNextHop

VPN IPv4 next hop

topology.BgpRoutesRouteTarget

VPN IPv4 route target

Topology operations
Table 21-4: Topology operation methods

Method

Description

topology.TopologyManager.constrainedShortestPathFirstGraphExt

Performs a CSPF calculation from the specified source to the specified destination, using the specified constraints, as known by the specified IGP protocol

topology.TopologyManager.igpShortestPathFirstGraphExt

Performs an SPF calculation from the specified source to the specified destination, using OSPF, IS-IS, or OSPF and IS-IS

topology.TopologyManager.nextHopExt

Calculates the next hop from all routers in the source set to the specified destination FEC

topology.TopologyManager.shortestPathFirstGraphExt

Performs an SPF calculation from the specified source to the specified destination using the specified IGP protocol

See Figure 21-7, find request example, SPF between two NEs for a method example.

Perform SPF calculation

Figure 21-7: find request example, SPF between two NEs
<topology.TopologyManager.shortestPathFirstGraphExt xmlns="xmlapi_1.0">
   <igpAdminDomain>tpgy-mgr:name-AdminDomain1-AS-1</igpAdminDomain>
   <protocol>ospf</protocol>
   <sourceType>ipv4</sourceType>
   <source>198.51.100.71</source>
   <sourceLen>32</sourceLen>
   <destType>ipv4</destType>
   <dest>198.51.100.72</dest>
   <destLen>32</destLen>
</topology.TopologyManager.shortestPathFirstGraphExt>

See the XML API Reference for descriptions of the input parameters. See the XML API SDK Sample Code Navigator under the Configuration/CPAM directory for other sample topology operation scripts and the results after executing these types of scripts.

Topology checkpoints

The CPAM can be used to analyze the effect of a network failure on services, IP paths, and LSPs, as well as configuration changes, dynamic changes such as LSP configuration, and reroutes during a specified time period. To analyze these effects, checkpoints can be configured and used to compare historical topology changes in a specified interval on the IGP topology.

A checkpoint object is a snapshot of a real topology object at a specific time. When you apply a checkpoint to a real network object, all of the properties of the real object at checkpoint time—for example, metric and bandwidth on IGP links—are copied to the checkpointed object.

After you have set up your network and the network is operational, you can checkpoint the network to create a snapshot of the current state and compare it with checkpoints collected at different times. An OSPF topology checkpoint is created for all of the OSPF areas in an IGP administrative domain. An ISIS routing topology checkpoint is created for all of the ISIS routing domains—Level 2 or Level 1—in an IGP administrative domain.

See “Topology management” in the NSP NFM-P Control Plane Assurance Manager User Guide for more information about topology checkpoints and objects that are included in OSPF and IS-IS checkpoints.

Checkpoint configuration workflow

The following workflow describes the configuration of checkpoints and the usage of checkpointed data.

 

Create topology checkpoints for an administrative domain.


Retrieve checkpointed data.


Compare checkpointed data.


Schedule automatic checkpoint creations.

Checkpoint creation

You can create checkpoints using the following methods:

Using the generic configure method

Using the autoCreateCheckpoints method

See the XML API Reference for descriptions of the input parameters. See the XML API SDK Sample Code Navigator under the Configuration/CPAM directory for a sample of these scripts.

Checkpointed data retrieval

After checkpoints are set, you can retrieve the checkpointed topology objects, such as routers, IGP links, and subnets. The following table shows the topology checkpoint information that can be retrieved.

Table 21-5: Checkpoint objects

Object

Package and class

OSPF

Area

topology.Area

Area Link

topology.OspfLink

Router

topology.Router

Area Subnet

topology.Subnet

IS-IS

Area

topology.Area

Domain Link

topology.IsisLink

Router

topology.Router

Domain Subnet

topology.IsisSubnet

Non-routed

Link

topology.NonRoutedLink

Subnet

topology.NonRoutedSubnet

You can retrieve checkpointed data using the following methods:

Using the getCpTopology method to retrieve checkpointed data

The following figure shows an example of a request that uses the getCpTopology method to retrieve checkpointed data.

Figure 21-8: Checkpointed data retrieval request example
<topology.Checkpoint.getCpTopology xmlns="xmlapi_1.0">
   <checkpointId>1</checkpointId>
   <asNumber>1</asNumber>
   <asName>AdminDomain-1</asName>
   <protocol>ospf</protocol>
   <fullClassName>topology.Router</fullClassName>
   <resultFilter/>
</topology.Checkpoint.getCpTopology>

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

A checkpointed object shares the same XML API class as a real-time topology object; therefore, in the find or findToFile method filter, you need the following to distinguish checkpointed data from real-time data.

For real-time data:

<equal name='isCheckpointObject' value='false'/>

For checkpointed data:

<equal name='isCheckpointObject' value='true'/>

Using the find method to retrieve checkpointed data

The following figure shows an example of a request to find checkpointed OSPF links that match a filter.

Figure 21-9: Checkpointed OSPF link retrieval request example
<find xmlns="xmlapi_1.0">
   <fullClassName>topology.OspfLink</fullClassName>
   <filter>
      <and>        
         <equal name="isCheckpointObject" value="true"/>
         <equal name="asName" value="igp0"/>
         <equal name="routerIdStr" value="198.51.100.57"/>
      </and>
   </filter>
</find>

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

Checkpoint comparison

You can use the CPAM to diagnose problems in the network by comparing two checkpoints of the network and viewing the information about the differences in configuration and topology changes.

When you compare two checkpoints, you can specify whether the comparison is of checkpointed areas, routers, links, or subnets, or a combination of these objects. The first checkpoint that you select is the basis for the comparison. You can swap the order of the checkpoints so that the second checkpoint that you select becomes the basis for the comparison. You can specify a filter to limit what comparison results are returned.

Comparing checkpointed data

Figure 21-10: Checkpoint comparison request example
<generic.GenericObject.triggerIncrementalRequest xmlns="xmlapi_1.0">
   <aInIncrementalContext>
      <generic.IncrementalContext> 
         <jmsClientId>JMS_client@n</jmsClientId>
         <handlerName>GEN_COMPARE_OBJECTS</handlerName>
         <appDefinedContext>
            <generic.ComparisonParam>
               <comparisonFilter>
                  <generic.ComparisonFilter>
                     <classesToProcess/>
                     <includeOnlyDiffs>true</includeOnlyDiffs>
                  </generic.ComparisonFilter>
               </comparisonFilter>
               <base>tpgy-mgr:name-igp0-AS-0:OspfCheckpoint-1</base>
               <compareTo>tpgy-mgr:name-igp0-AS-0:OspfCheckpoint-3</compareTo>
            </generic.ComparisonParam>
         </appDefinedContext>      
      </generic.IncrementalContext>
   </aInIncrementalContext>
</generic.GenericObject.triggerIncrementalRequest>

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

The result of the comparison is retrieved through the JMS interface. An OSS needs to subscribe to JMS to receive the result. See Chapter 4, Event monitoring using JMS for information about how to connect and subscribe to JMS.

For a response, look for the JMS client ID that you specified in the request in   Figure 21-10, Checkpoint comparison request example in the ALA_clientId attribute in the JMS message header and also filter for the IncrementalRequestEvent in the JMS message header.

Figure 21-11: IncrementalRequestEvent JMS header example
<header xmlns="xmlapi_1.0">
   <eventName>IncrementalRequestEvent</eventName>
   <ALA_category>GENERAL</ALA_category>
   <ALA_OLC>0</ALA_OLC>
   <ALA_isVessel>false</ALA_isVessel>
   <ALA_allomorphic/>
   <MTOSI_osTime>1300820624174</MTOSI_osTime>
   <MTOSI_NTType>ALA_OTHER</MTOSI_NTType>
   <MTOSI_objectName/>
   <ALA_clientId>JMS_client@n</ALA_clientId>
   <MTOSI_objectType>IncrementalRequestEvent</MTOSI_objectType>
   <ALA_eventName>IncrementalRequestEvent</ALA_eventName>
</header>

See the XML API SDK Sample Code Navigator under the Configuration/CPAM directory for a sample of the complete JMS event in response to the request in   Figure 21-10, Checkpoint comparison request example .

Checkpoint schedule policies

Checkpoints can be automatically created using a schedule. Scheduled checkpoint creation requires a checkpoint schedule policy and checkpoint scheduled task. See “Topology checkpoints” in the NSP NFM-P Control Plane Assurance Manager User Guide for information about how to configure checkpoint schedule policies and scheduled tasks, and for considerations specific to checkpoint scheduled task creation. See “NFM-P-based schedules” in the NSP NFM-P Classic Management User Guide for general information about schedules and scheduled tasks.

The following are the classes for scheduling checkpoints and defining schedule policies:

© 2023 Nokia. Nokia Confidential Information

Use subject to agreed restrictions on disclosure and use.