Overview
Preconfiguration
A GNE requires preconfiguration for NFM-P management. When the preconfiguration is complete, the NFM-P can discover the device, as described in Chapter 9, Device discovery .
The NFM-P uses configurable profiles and CLI configuration scripts to discover and manage GNEs. You can use one GNE profile for multiple GNEs of the same type.
By default, only the NFM-P admin user, or a user with an assigned admin scope of command role, can manage GNE objects. To create and configure GNE objects, a non-admin user requires a scope of command role that has Create and Update/Execute permissions on packages and classes that include the following:
-
security.MediationPolicy and snmp.PollerManager—to create mediation policies
-
trapmapper—to create alarm catalogs that map SNMP traps to NFM-P alarms
The NFM-P can discover a device as a GNE only when the following conditions are in place.
-
The GNE preconfiguration is complete.
-
The System Object ID of the GNE is required for the GNE Profile, for example 1.3.6.1.4.1. When multiple GNE profiles contain possible matches for a system object ID, the profile that contains the system object ID with the longest or most specific match is chosen.
-
SNMP and/or NETCONF is configured and enabled on the device, as appropriate.
-
-
An NFM-P mediation policy is configured with SNMP and NETCONF settings that match the device configuration.
See Workflow to commission GNEs for the GNE commissioning workflow. See Chapter 9, Device discovery for information about mediation policies and device discovery.
NFM-P upgrade and native GNE management
If an NFM-P system that is to be upgraded manages a device as a GNE, and the new NFM-P release supports native management of the device, you must unmanage the device and delete it from the NFM-P database before the upgrade.
After the upgrade, you can use the NFM-P to discover and manage the device natively, rather than as a GNE.
Note: GNE management cannot be used to extend the release support of a device. The same release compatibility between NEs and NFM-P applies whether the device is natively managed or managed as a GNE.
Invoking alternate element managers
If an EMS client application for a GNE is installed on an NFM-P GUI client station, you can use a right-click GNE menu option in the network navigation tree to open the EMS client application. The OS-level command that opens the client must be specified in the associated GNE profile, or in the individual GNE configuration, to enable the function. A command in the configuration of a specific GNE overrides a command in the associated GNE profile.
If the command path is not included, the NFM-P attempts to locate the command using the paths listed in the PATH environment variable of the client station OS.
If the command that opens an EMS client accepts an NE IP address as an argument, you can specify the address using a keyword in the command entry. The NFM-P replaces the keyword with the target GNE IP address as it runs the command.
An alternate GNE manager is configurable using the GUI or OSS. See To prepare a GNE for NFM-P management for information about configuring an alternate EMS in a GNE profile. See To configure an alternate EMS for a specific GNE for information about specifying an alternate EMS in the GNE configuration.
GNE profiles
NFM-P management of a device as a GNE requires a GNE profile, which defines how the NFM-P communicates with the device. A GNE profile includes the following elements:
-
the interfaces that can be specified as the endpoints of NFM-P physical links
-
an SNMP trap management configuration that associates trap configuration and deconfiguration scripts with the profile
-
an optional alarm catalog that defines the alarms that the NFM-P raises in response to SNMP traps from the device