What is NFM-P system maintenance?

Introduction

The implementation of a regular maintenance schedule is recommended in order to:

NFM-P system maintenance begins with the establishment of base measures against which to evaluate the system functionality and correct any performance or connectivity issues.

NFM-P OLC states

You can put NEs in maintenance mode using OLC states, as described in Setting NFM-P OLC states.

NFM-P base measures

Maintenance base measures can be used by NOC operations or engineering staff who are responsible for maintenance issues to evaluate the activity and performance of network components, for example, client GUI response times when listing equipment.

The data from a series of base measures can be used, over time, to track performance trends. For example, if there are reports that client GUI response times for listing equipment degrades over time, you can use the base measures to determine how much performance has degraded. The procedures in this guide can help narrow the search for the cause of performance degradation.

It is recommended to do the following:

This section provides base measure information for:

Establishing base measures

Base measures can be affected by issues that are beyond the scope of this guide, including:

The NFM-P service test manager (STM) provides the ability to group OAM diagnostic tests into test suites that you can run as scheduled tasks. You can customize a test suite to your network topology and execute the test suite to establish baseline performance information. You can retain the test suite, modify it to accommodate network topology changes, and execute the test suite to establish new base measures as required. Scheduled execution of the test suite and regular review of the results may reveal deviations from the baseline. See the NSP NFM-P User Guide for information about using the STM and creating scheduled tasks.

Platform base measures

You can use platform base measures to:

Table 21-4: Platform base data

Component

Platform information

Main server 1

RAM:

CPU (quantity, type, speed):

OS version and patch level:

Main database 1

RAM:

CPU (quantity, type, speed):

OS version and patch level:

Main server 2

RAM:

CPU (quantity, type, speed):

OS version and patch level:

Swap space:

Disk slices:

Main database 2

RAM:

CPU (quantity, type, speed):

OS version and patch level:

Swap space:

Database disk file systems:

Disk slice sizes:

Auxiliary server 1

RAM:

CPU (quantity, type, speed):

OS version and patch level:

Swap space:

Disk slice sizes:

Auxiliary server 2

RAM:

CPU (quantity, type, speed):

OS version and patch level:

Swap space:

Disk slice sizes:

Auxiliary server 1

RAM:

CPU (quantity, type, speed):

OS version and patch level:

Swap space:

Disk slice sizes:

Auxiliary server 2

RAM:

CPU (quantity, type, speed):

OS version and patch level:

Swap space:

Disk slice sizes:

Client delegate server

OS type, version, patch level:

RAM:

CPU:

Disk space:

Monitor:

Graphics card:

Single-user GUI client

OS type, version, patch level:

RAM:

CPU:

Disk space:

Monitor:

Graphics card:

Single-user GUI client

RAM:

CPU:

OS type, version, patch level:

Disk space:

Monitor:

Graphics card:

Inventory base measures

You can use inventory base measures to:

Use the following sequence to create inventory base measures, for example, for access ports. You can modify the sequence to create additional inventory base measures for other objects.

  1. Determine the type of object data for which you need to create inventory records, for example, access ports.

  2. List the ports of all managed network devices using the client GUI manage equipment window or create an XML API request to generate the list.

  3. Format the inventory for future processing, based on your inventory processing requirements.

  4. Generate the inventory data, using the same listing and filtering criteria, on a weekly or monthly basis, as necessary to track changes to the network.

    When new devices are added to the network on a regular basis, increase the inventory frequency.

  5. Use the generated list to record the current inventory of network objects and as a baseline measure of performance.

    For example, baseline the time required to generate a client GUI list of 1000 access ports.

    When an access port list is later generated, record the time required to generate the list using 2000 ports. Ideally, it takes twice as long to list twice as many ports; if the ratio of listing time to number of ports is highly nonlinear, there may be scalability issues that require investigation.

Performance and scalability base measures

You can use the following performance and scalability base measures to:

Table 21-5: Scalability base measures

Type of base measure

System limits

Expected response time

Network base measure response time

Additional information

Total devices managed

See the appropriate NSP NFM-P Release Description and NSP Planning Guide for information about release-specific system limits.

The client GUI is operational XX seconds after launching.

The time to open icons in the Equipment navigation tree increases depending on the number of configured MDAs.

Total services

  • XML API configuration of 300 VLL services in X min

  • XML API configuration of 100 VPLS services with 3 sites and one SAP in 5 min

The complexity of the service configuration affects response time. For example, adding additional SAPs to a VPLS increases provisioning time.

Outstanding alarms

The client GUI is able to retrieve and display XX 000 alarms in the dynamic alarm list during startup.

Client GUIs for each server

Open a configuration form using the client GUI in X amount of time.

Measure X against a constant platform size over time

Device discovery

Discover one additional device with an IP address in the X.X.X.1 to 255 range in less than 1 min.

Performance base measures

For networks, commonly available tools such as ping, which measures round trip time using ICMP, can be used to determine quantities such as packet loss and round trip delay. See the ping command information in this guide, and the NSP Troubleshooting Guide, for more information about performing the commands.

You can baseline the packet loss results and round trip delay times for specific NMS LAN and network scenarios. Record those results for future baselines against regularly run packet loss and round trip delay tests.

Reachability base measures

System reachability is important in business-critical systems. Service reachability components are:

The types of measures and baselines necessary to ensure reachability and availability are network-dependent, and vary depending on the topology of the network, the networking technologies used to move data, and the types of equipment used.

NE reachability

A test point is reachable from a testing measurement agent when the agent can send packets to the test point and receive a response from the test point that the packet was received. The ping test and the OAM diagnostics using the NFM-P or device CLI can test reachability. Record the test results to create a measurement baseline.

These tests can be performed when you troubleshoot a customer service, or when you perform SLA tests before you enable a customer service.

Service availability

The network between a measurement agent and a test point is considered available at a given time when the measured packet loss rate and the round trip delays are both below pre-defined thresholds. The threshold values are dependent on network topology. The ping test and the OAM diagnostics using the NFM-P or CLI to a device can test service availability. Record the test results to create a measurement baseline.

Service outage duration

The duration of an outage is defined as the difference between the time a service becomes unavailable and the time it is restored. Time between outages is defined as the difference between the start times of two consecutive outages. Troubleshooters that resolve customer problems, or the data generated to resolve SLAs, can provide the baseline metrics to measure outages, and the time between outages. Record the information to create a measurement baseline.