Impact analysis overview
Introduction to impact analysis
You can use the CPAM to analyze the impact of a network failure on services, IP paths, and LSPs, in addition to configuration changes, dynamic changes such as LSP configuration, and reroutes, during a specified time period.
IGP history
You can use checkpoints to compare historical topology changes within a specified interval on the IGP topology map. See Topology checkpoints for information about checkpoints.
You can compare two checkpoints in the selected interval to view property changes on objects that belong to both checkpoints. The CPAM uses the checkpoints that are closest to the selected interval. See Troubleshooting the network by comparing checkpoints for information.
If checkpoints have been created and not cleaned up during the selected interval, the IGP history window shows topology changes during the interval. Changes are displayed in different colors and line types. The following link colours indicate topology changes between the start and end of the interval:
-
dashed green line with yellow outline—links added with property changes over interval
-
red—links deleted (operational state down at end of interval, missing link)
-
dashed red line with yellow outline—property changes during interval and links deleted (operational state down at end of interval, missing link)
-
yellow—some properties on the link changed; no changes to operational state
-
purple—more than one change to operational state occurred during interval, which may indicate link flapping
-
purple dashed line with yellow outline—properties changed during interval and operational state changed at least once during interval (property change and flapping)
The following figure shows an IGP history topology map:
Figure 18-1: IGP history topology map
Topology checkpoints
A checkpointed 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. A checkpointed object is displayed in the same manner as the real topology object, and shares the same OSS class name.
After you have set up the network and the network is operational, you can checkpoint the network to create a snapshot of the current state—which can include routers, links, metric configuration, or bandwidth usage—and compare it with checkpoints collected at different times. In addition, you can compare the results on an IGP history map.
Note: If one or more links go down and are cleaned up between two checkpoints being taken, there will be no indication on the IGP history map that these links were down. From the perspective of a user, the IGP history map shows no changes within their network.
An OSPF topology checkpoint is created for all of the OSPF areas within an IGP administrative domain. See OSPF checkpoints for information about OSPF topology checkpoints. An ISIS topology checkpoint is created for all of the ISIS routing domains—Level 2 or Level 1—within an IGP administrative domain. See ISIS checkpoints for information about ISIS topology checkpoints.
Note: In OSPF, a routing domain is an OSPF area. In ISIS, a routing domain does not map to the ISIS area, but rather a group of routers that are participating in an ISIS level.
The OSPF and ISIS topology checkpoints are objects of the IGP administrative domain object.
The figure below shows the properties form for an IGP administrative domain. The OSPF and ISIS checkpoints within the IGP administrative domain are listed. In addition, you can access checkpoint schedule policies for the IGP administrative domain.
Figure 18-2: IGP administrative domain
OSPF checkpoints
You can create an OSPF checkpoint for all of the OSPF areas within an IGP administrative domain.
The OSPF objects that are included in an OSPF checkpoint are:
The following figure shows the properties form for an OSPF checkpoint:
Figure 18-3: OSPF checkpoint
ISIS checkpoints
You can create an ISIS checkpoint for all of the ISIS routing domains within an IGP administrative domain.
The ISIS objects that are included in an ISIS checkpoint are:
The following figure shows the properties form for an ISIS checkpoint.:
Figure 18-4: ISIS checkpoint
CPAM checkpoint manager
You can use the CPAM checkpoint manager to:
-
search for and view specific OSPF or ISIS topology checkpoints
-
search for and view checkpointed topology objects, such as routers, IGP links, or subnets
You can create checkpoints by:
A topology object is created as a result of a checkpoint if the object changed since the previous checkpoint. When checkpoints are used for comparisons and IGP history, full topology information is recovered.
Checkpoint schedule policies
You can use the checkpoint manager to schedule checkpoints by creating checkpoint schedule policies. The scheduling function supports the creation of NFM-P-based schedules for the automatic execution of checkpoint tasks at specified times.
You can associate a schedule that you create with a checkpoint scheduled task that can be immediately processed, scheduled for later execution, or retained for future use. A scheduled task must be created in the checkpoint scheduler policy configuration form for the scheduled task. When scheduled tasks are created they are associated with a schedule. A schedule is configurable for one-time or ongoing task execution. You can optionally specify the time at which an ongoing schedule is to stop functioning.
To simplify the creation of NFM-P-based schedules when the user and server are in different time zones, the NFM-P converts and displays schedule times that apply to the user and server. For example, if a user in Chicago needs to schedule a checkpoint scheduled task on a system located in New York, both the user and server local times are displayed. The NFM-P calculates the time difference for the user.
User time zones are configured on the User Preferences form. If a time zone is not configured, the NFM-P uses the time zone of the GUI client. If the time zone is not one of the supported time zone options, the NFM-P displays the time zone ID and uses the GMT time value without the time zone offset.
The NFM-P displays whether daylight savings mode is in effect for the client and server. The daylight saving time is specified for the user start time and is based on the time zone of the user. The daylight savings time does not specify the current time and end time.
Consider the following when you create a checkpoint schedule policy or a scheduled checkpoint task.
-
Ensure that scheduled tasks are run sufficiently far apart to allow one task to finish before the next starts. Otherwise, the next occurrence of the task is skipped or delayed if the delay time is configured. There is a minimum time interval of 5 minutes for checkpoint creation. For IGP history, you must choose the appropriate time interval—the shorter interval, the shorter IGP History. Changes are located more precisely in time.
-
Do not create schedules that overlap. If a new checkpoint creation overlaps with a previous checkpoint or background cleanup task, the checkpoint will not be created.
-
A new scheduled task is shut down by default and must be turned up before it can be run.
-
You cannot delete a schedule that has a dependency, for example, one that is associated with a task. To delete and IGP administrative domain Schedule Policy, you must first delete the scheduled task.
-
One minute is added to the default start and end time values of a schedule to allow time for schedule configuration.
-
A monthly schedule with the Run Every Month or Run Every Months parameter configured uses a 30-day interval.
-
When you create a monthly schedule using the Run Every parameter and specify a date that does not exist for the specified months, the last date of the month is used. For example, if you create a monthly scheduled task, starting January 31st, the scheduled task runs on February 28th, March 31st, and April 30th when those months are specified in the schedule.
Checkpoint configuration for IGP history
For the IGP history topology map to be accurate, you must configure the maximumNumberOfCheckpointObjects variable in the nms-server.xml file.
This variable limits the number of topology objects (checkpoints, routers, subnets and links) that are kept in the database to provide IGP history data. The larger this variable, the longer the IGP history is kept and more database space is consumed. Every time the number of objects reaches a threshold, the IGP history background cleanup task begins and removes older objects so that the total number of IGP history objects is lower than the maximumNumberOfCheckpointObjects.
Consider the following steps when you set the maximumNumberOfCheckpointObjects based on network size and stability:
-
1. Calculate the required maximum number using the following formula:
Required Maximum Number Of Checkpoint Objects = #Routers x (1 + ExpansionFactor) x (1 + PercentChange x HoldTime) x FluctuationFactor
where,
FluctuationFactor is 3
#Routers is the number of routers in the network (if a router is part of both OSPF and ISIS, it counts as 2)
ExpansionFactor is average number of links and subnets per router in the network
PercentChange is the measure of stability of the network and is equal to (topology object changed)/(total objects) per month. Operational state changes, metrics re-configurations, bandwidth on links etc. are considered changes. Although you cannot precisely predict this parameter, this value is assumed to be 0.1 per month, based on statistical data. This means that in a normal and stable network, 10% of topology objects (routers, subnets, links) are changed.
HoldTime is the desired time interval in months that a user wants to keep IGP history.
For example, for the average size network with #Routers = 500, ExpansionFactor = 10, PercentChange = 0.1/month, HoldTime = 6 month, the Required Maximum Number Of Checkpoint Objects is 26 400.
-
2. Set maximumNumberOfCheckpointObjects to the larger number of Required Maximum Number Of Checkpoint Objects calculated in step 1, or 50 000.
The default value of maximumNumberOfCheckpointObjects is set to 50000 based on the average sized network.
-
3. If the number from step 2 is greater than 100 000, set the maximumNumberOfCheckpointObjects to 100 000.
Troubleshooting the network by comparing checkpoints
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. It is also possible to compare a single checkpoint against the current topology rather than a second checkpoint.
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.
You can compare checkpoints from:
When you use the Checkpoint manager to compare checkpoints, you can choose the checkpoints to be compared. When you use the IGP history topology map, the CPAM chooses the two checkpoints in the specified interval that are closest to the start and end dates and times.
The first checkpoint that you select or that is selected by the CPAM in the IGP historical interval is the base for the comparison. You can change the order of the checkpoints so that the second checkpoint that you select becomes the base for the comparison. You can specify a filter to limit the comparison results that are displayed. The CPAM displays a list of the object comparison results, with an entry for each checkpointed object that is compared.
You can view information about the property differences for a specific object, such as a router or link. Differences between the values of a property in the first and second checkpoints are indicated by text, icons, and colors.
Note: See To compare checkpoints for information about how to compare checkpoints.
The objects involved in an OSPF checkpoint comparison include the following:
The objects involved in an ISIS checkpoint comparison include the following:
© 2024 Nokia. Nokia Confidential Information
Use subject to agreed restrictions on disclosure and use.