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:

• OSPF

• OSPFv3

• IS-IS

• IGP

• BGP

• MPLS—MPLS and LDP information is collected from the NFM-P

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

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

• method—find

• fullClassName—the class where data is to be retrieved from. For Figure 21-6, find request example, IGP links , the class is the topology.IgpLink class.

• filter—set a filter to only return IGP link objects that satisfy the filter criteria

  • The filter criteria is to look for real-time data (not checkpointed data), with administrative domain name of igp0, and router ID of 198.51.100.57.

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:

• BGP AS

• BGP Confederation AS

• BGP Sub-AS

Table 21-3: BGP topology objects

Topology operations

Table 21-4: Topology operation methods

Perform SPF calculation

• method — topology. TopologyManager.shortestPathFirstGraphExt

• <igpAdminDomain> — tpgy-mgr:name-${displayedName}-AS-${asNumber}, which is a pointer to the IGP administrative domain to perform the SPF in. 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 topology.AutonomousSystem class.

• <protocol>—sets the protocol to run SPF on

• <sourceType>—sets the address type of the source

• <source>— ets the source address

• <sourceLen>—sets the length of the source address

• <destType>—sets the address type of the destination

• <dest>—sets the destination address

• <destLen>— ets the length of the destination address

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.

Checkpoint creation

You can create checkpoints using the following methods:

• using the generic configure method and the appropriate classes, such as topology.OspfCheckpoint and topology.IsisCheckpoint. This method creates a specific type, OSPF or IS-IS, of checkpoint in an IGP administrative domain. A name and description can be set for the checkpoint.

• using the topology.Checkpoint.autoCreateCheckpoints method. This method creates all supported types, such as OSPF, IS-IS, of checkpoints at once, or creates a combination of the supported types of checkpoints in an IGP administrative domain.

Using the generic configure method

• method—generic.GenericObject.configureChildInstance

• distinguishedName—tpgy-mgr:name-${displayedName}-AS-${asNumber}. The FDN can be determined by looking at the Parent Hierarchy of the class to be created in the XML API Reference.

• childConfigInfo—creates and configures the following parameters:

  • Checkpoint object:

    •    for OSPF checkpoint - topology.OspfCheckpoint

    •    for IS-IS checkpoint - topology.IsisCheckpoint

  • actionMask - specifies the create operation

  • <id> - (optional) assigns a unique ID. If not specified, the NFM-P automatically assigns the ID.

  • <displayedName> - assigns a unique name

  • <description> - describes the checkpoint

Using the autoCreateCheckpoints method

• method—topology.Checkpoint.autoCreateCheckpoints

• <igpAdminDomain> — tpgy-mgr:name-${displayedName}-AS-${asNumber} is a pointer to the IGP administrative domain that is being checkpointed. The FDN can be determined by looking at the Parent Hierarchy of the class to be created in the XML API Reference.

• <protocolMask>—sets the protocols. Set all the applicable bits.

  • <bit> - topology.CheckPoint bitmask value

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

You can retrieve checkpointed data using the following methods:

• Using the topology.Checkpoint.getCpTopology method. This method retrieves only the objects that exist in the specified checkpoint.

• Using the find or findToFile method with the appropriate classes specified in Table 21-5, Checkpoint objects , and a filter. This method retrieves objects in different checkpoints depending on what is specified in the filter.

Using the getCpTopology method to retrieve checkpointed data

• method—topology.Checkpoint.getCpTopology

• <checkpointId> — ID of the checkpoint from where to retrieve data

• <asNumber>—IGP administrative domain number of the checkpoint

• <asName> — IGP administrative domain name of the checkpoint

• <protocol>—protocol to which the checkpoint belongs, which is ospf for OSPF, or isis for IS-IS.

• <fullClassName> — list of checkpointed objects, from Table 21-5, Checkpoint objects , separated by a comma. For example, topology.Router, topology.OspfLink

• <resultFilter>—(optional) filter for reducing the scope of the returned information

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

• method—find

• fullClassName—the class where data is to be retrieved from. For Figure 21-9, Checkpointed OSPF link retrieval request example , the class is the topology.OspfLink class.

• filter—sets a filter to only return OSPF link objects that satisfy the filter criteria

  • The filter criteria is to look for checkpointed data, with administrative domain name of igp0, and router ID of 198.51.100.57.

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

• method—generic.GenericObject.triggerIncrementalRequest

• <alnIncrementalContext>—Application specific configuration parameters are set inside this tag.

  • <generic.IncrementalContext> - structure that contains the parameters for this method

  • <jmsClientId> - sets the JMS client ID. The ID can be used to filter JMS events for the result.

  • <handlerName> - specifies the application to run. In this case, the application is the compare object that needs to be set to GEN_COMPARE_OBJECTS.

  • <appDefinedContext> - sets the parameters for the handler

         •    <generic.ComparisonParam>—structure for the parameters for the comparison

                      •    <comparisonFilter> - reduces scope of comparison

                      •     <base> - basis of comparison

                      •     <compareTo> - basis if being compared to this object

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:

• topology.CheckpointScheduledTask

  represents a specialized Checkpoint Scheduled Task used for performing scheduled checkpoints

• topology.CpSchedulePolicy

  defines the policy for creating scheduled checkpoints