Policies

Overview

The NFM-P supports the template-based creation of rules that govern how network traffic is handled and prioritized. These rules are referred to as policies. Policies provide a consistent, centralized configuration of common characteristics across multiple objects in the network. An NFM-P operator can distribute or delete policies on sites and NEs that are within their span of control.

You can assign policies to resources during service creation or modification. You can also assign policies to resources before or after you configure the service by choosing and modifying the resource from the Manage Equipment or Manage Services form.

Service and routing management policies are globally and seamlessly distributed to devices when they are used by resources on the device. They can also be manually distributed to devices. Subsequent changes to policies are distributed and affect all participating resources. Policy configurations can also be changed locally when you configure a network resource, for example, during service configuration or modification. These changes do not affect the global policy.

Global versus local policies

Policies are Global or Local in scope. Global policies are created using the NFM-P and are available for use throughout the network. Local policies are instances of global policies that are assigned to individual NEs and may contain properties applicable only to that NE.

When you modify and distribute a global policy using the NFM-P, the local policy definition is also updated, provided that its distribution mode is set to Sync With Global. This ensures that the policy instances are synchronized. If a local policy differs from the corresponding global policy because of changes to the global policy, a warning alarm is raised against the local policy. After a global policy is updated and distributed to the participating NEs, the NFM-P clears the mismatch alarms associated with the local policy.

When there is no global policy associated with a local policy, the NFM-P automatically creates a global policy that is identical to the first discovered local policy. If the local policy is incomplete, the NFM-P creates an incomplete global policy.

Global policies states

When you initially select a policy type under the main Policies menu, a selection window is displayed that lists all occurrences. You can choose to display Global or Local policies here. When you select Global, the menu bar over the list displays filterable and read-only parameters pertinent to the chosen policy type. The following read-only parameters describe the initialization phases of a Global policy:

• Discovery State

  The Discovery State parameter describes the state of the global policy during node discovery, or if a local policy on an NE is created or modified using CLI after the NE is discovered. The following may be displayed:

  • In Progress—the global policy is created as part of node discovery, and the policy definition is not yet complete.

  • Completed—the global policy is created as part of node discovery, and the global policy definition is successful and complete.

  • Failed—the global policy is created as part of node discovery, and the policy definition is not successful. This may occur because of an NFM-P server failure or activity switch. A failed global policy is updated during the next successful full NE resynchronization, or the policy can be manually synchronized with a specific local policy.

  • Initialized—the global policy is created by SNMP trap notification from a local policy that was created or modified on the NE by CLI after NE discovery. User may need to synchronize the global policy manually with the specific local policy. After such a policy synchronization on an “Initialized” global policy (using the NFM-P), the Discovery State for the global policy changes to “N/A”.

  • N/A (default)—the global policy is created or modified by an NFM-P user, and not as a result of NE discovery or CLI change.

• Last Sync Time

  The Last Sync Time field provides date and time information concerning the current state of an existing global policy that you are viewing.

  Note:

  This field displays “N/A” when you are first creating the global policy in the NFM-P.

  The Last Sync Time information field may denote any of the following timestamps:

  • the date and time when a policy that was created on an NE (using the CLI) was discovered by the NFM-P

  • the most recent date and time that the global policy was synchronized by the NFM-P with a corresponding local definition on an NE

  • N/A, indicating that the NFM-P has undergone an upgrade since the creation time of the global policy

• Last Sync From

  The Last Sync From field provides information concerning the origin of an existing global policy that you are viewing.

  Note:

  This field displays “N/A” when you are first creating the global policy in the NFM-P, and then “admin” once the policy is initially applied.

  The Last Sync From information field may denote any of the following origins:

  • NFM-P user name (for instance, admin), indicating that the policy was created from the NFM-P

  • System ID, indicating the NE from which the policy was learned by the NFM-P

  • System ID, indicating the NE with which the policy was most recently synchronized by the NFM-P

  • N/A, indicating that the NFM-P has undergone an upgrade since the creation of the global policy

Note: If you attempt to modify a global policy with an “In Progress” Discovery State, the following occurs:

• When discovery of the NE is ongoing, the modification fails.

• When discovery of the NE is completed, modifications using OSS proceed, although a warning appears and allows you to cancel the modification. If the modification is not canceled, the Discovery State is changed to N/A, and the global policy is not updated to match the local policy.

• When a global policy is modified, the Discovery State is reset to N/A.

At any time during discovery or a full resynchronization, you can use the SyncTo method from OSS or synchronize the global policy from any local policy.

When a discovery of an NE fails and there is no NFM-P server failure or activity switch, all global policies that are waiting for completion are changed to Failed for the Discovery State. If you start another full resynchronization of the failed NE, the NFM-P tries again to complete the global policies from the NE that is part of the resynchronization and which has the Failed or In Progress Discovery State. The NFM-P also attempts completion of the synchronization of global policies that have a Failed or an In Progress State until a server failure or an activity switch occurs.

The following table describes the recommended operator actions to recover global policies when the Discovery State remains In Progress or Failed.

Table 49-1: Actions to recover global policies

Discovery State	NFM-P server failure	NE state	Recovery action
In Progress/Failed	No	Resync Failed	Retry a full resynchronization or synchronization from another local policy
In Progress/Failed	No/Yes	Removed/Unmanaged	Synchronization from another local policy
In Progress/Failed	Yes	Resync Completed	Synchronization from another local policy
In Progress/Failed	Yes	Resync Failed	Retry a full resynchronization and synchronization from another local policy

Default global policy creation

When an NE is discovered, if a given global policy on the NE is not present in the NFM-P, then a non-empty global policy is created in the NFM-P. It has the same content as the originating NE's policy. The local definition specific to the NE is set to “Sync With Global”, unless the originating policy is a routing policy, in which case the local definition is set to “Local Edit Only”.

When a global policy (other than a routing policy) is created using CLI on an NE already known to the NFM-P, the behavior is different. In this case, the NFM-P creates a new resynched global policy with only default mandatory values (for example, default queues). The NFM-P global policy does not contain objects specific to the NE-originated policy, such as filter entries. However, such objects are contained in the local definition specific to the NE. This local definition is set to “Local Edit Only”. In the case of a 7210 and 1830 Network policy, the local definition is set to “Sync With Global”, and the global policy created will be a copy of the local policy. For a CLI-created routing policy on a discovered NE, a non-empty global policy is created in the NFM-P. The global policy will be in sync with the local routing policy.

Policy audits

Nokia recommends that you change a policy on an NE using only the NFM-P or an OSS client. This ensures that there is no mismatch in policy IDs or policy configurations between the managed NEs and the NFM-P.

Creating or modifying a policy using a CLI may lead to inconsistencies in the policy configuration throughout the network.

Note: For policies that require you to enter a name to identify the policy, you cannot use “N/A” for the policy name; the term N/A is restricted.

Local changes to a policy may occur where users have permissions to access local policies using CLI. To identify local and global policy mismatches, you can perform a policy audit that compares the local and global instances of a policy, and then review the differences. Note however that the audit functionality is not applicable to non-modifiable default NFM-P policies. An audit can be performed on local policies of NEs that are in the user span of control.

You can audit all policies in the network or on selected NEs in the following ways:

• by policy group

• by policy type

• by global policy

If an entry exists in both the global and a local version of a policy but a field within that entry is different between the versions, then the audit indicates exactly which field is different. This includes missing entries as well. See To perform a policy audit for global policy and  To identify differences between a global and local policy or two local policies for information about identifying policy discrepancies using a policy audit.

If there is a mismatch between a local policy instance and the global instance, an alarm is raised against the local policy. The NFM-P clears the alarms from previous audits if the mismatch condition no longer exists.

Depending on the results of an audit, the mode of the local policy may change. If the audit discovers differences between the local and global policies, you can change the mode to allow only local configuration. When the audit discovers that the local policy and global policy match, the local mode can be changed to synchronize with global policies. For example, when you need the NFM-P to discover new NEs, set the mode parameter to local configuration only to ensure that unique policies are not modified when a global policy is updated. The audit results can be reviewed to determine whether a policy should remain local.

Policy synchronization

Changes to a local policy made using CLI will not result in a change to the related global policy. If you perform a policy audit of managed NEs and identify that the policy configuration is modified and the policies are out of sync, you can initiate a policy synchronization of the global policy with a selected local policy.

You can also do the reverse action, namely, update the global policy with a local policy definition and then release and re-distribute the policy to all deployed NEs. To prevent a catastrophic deployment of an invalid policy, the NFM-P changes the global policy to draft mode, and it is not available for use until the policy is released. See To synchronize a policy for information about how to synchronize a policy.

Policy overrides

With some policy types, you can use the NFM-P to configure a policy override that allows you to change or override the default settings associated with the policy. Policy overrides are typically configured on the object to which the policy is assigned.

For policy types that allow multiple overrides to be configured, the Override Policy Items tab on the policy creation form displays all of the subordinate override policies that are configured on the policy. Each override policy is displayed on their own sub-tabs under the Override Policy Items tab. The override policies that appear on the GUI are dynamic, based on the policy type to be configured.