Wavence management
Supported management traffic types
A Wavence device requires preconfiguration before NFM-P management of the device is possible. NFM-P supports in-band and out-of-band management of devices.
When you configure in-band management only, management traffic between NFM-P and a Wavence is transmitted through any port that is configured for network access, but not the management port. Using in-band management, NFM-P sends management traffic to the system IP address of the device, or to an optional L3 management interface.
When you configure out-of-band management only, management traffic between NFM-P and a Wavence is transmitted through the management port of the device. Using out-of-band management, NFM-P sends management traffic to the management IP address of the device. See the NSP NFM-P Classic Management User Guide for more information about device bandwidth management.
Note: A Wavence device can be managed by up to five instances of NFM-P.
In-band management of Wavence devices
To enable Wavence in-band management, NFM-P requires connectivity to the Wavence NE, as shown in Figure 2-1, Example of Wavence in-band management and described in the associated example configuration steps. Ensure that the trap receiving interface on the NFM-P server is configured with the IP address of the in-band NIC that connects to the Wavence network.
Figure 2-1: Example of Wavence in-band management
Perform the following initial configuration on the Wavence:
-
Connect Wavence Node 1 to the switch using the TMN port or port 4 of the Wavence A.
When NFM-P is connected to the Wavence network via non-Wavence devices like the 7705 SAR or 7750 SR, expect that the TMN in-band feature is enabled on Node 1 of the Wavence that is connected to non-Wavence devices. For example:
NFM-P → 7705 SAR_1/1/1 → port1/4_Wavence1 → (Radio) → Wavence2
In the preceding example, Wavence Node 1 and port 1/4 are enabled with VLAN ID and IP addresses, and the 7705 SAR is configured with the same VLAN and IP address from the same subnet.
-
Ensure that the Radio links between the Wavences are working by pinging the local IP addresses. A connection between two Wavence NEs could be over an Ethernet or optical link. If the core Ethernet or core optical port is used between two Wavences, the ports should be enabled with TMN in-band on the Wavence.
Note: The management port IP, TMN in-band IP, and local IP can be in different subnets.
Perform the following network configuration:
-
Verify that you can ping the local IP address of all the NEs from the NFM-P server.
-
Verify that you can ping the NFM-P server IP address from each of the Wavence NEs.
Note: You can manage the Wavence through the local IP address even though the management interface of the NFM-P server is not reachable.
-
NFM-P should be able to discover and manage the local IP addresses of the Wavences after connectivity is established between the NFM-P and the Wavence NEs.
LAC management of Wavence devices
Introduction
NFM-P provides a Local Access Control (LAC) management synchronization mechanism to allow or deny (inhibit) user access to configure Wavence devices using a Local Craft Terminal (LCT). This prevents multi-write access sessions on Wavence devices. You can also enable or disable whether NFM-P receives LAC alarms from the nodes.
Enable LAC management
You can enable LAC management by configuring the Enable LAC Management parameter on the MPR tab of the Administration→System Preference→System Preference form. Enabling LAC management automatically denies LCT access to nodes that are newly managed only. There is no impact to existing managed Wavence nodes.
After the Enable LAC Management parameter is configured, you can enable or disable LAC alarms by configuring the Enable LAC Alarms parameter on the MPR tab of the Administration→System Preference→System Preference form. NFM-P generates a “LAC requested” alarm indicating LCT use is requesting access to the node. When disabled, no new alarms will be generated. The Enable LAC Alarms parameter cannot be configured if the Enable LAC Management parameter is disabled.
Note: The Enable LAC Management parameter is disabled by default. Therefore, the LAC state of any node that is newly managed by NFM-P will not be altered. This is done to allow LCT access for those users who normally provision the Wavence using a Wavence element manager or the 1350 OMS.
LAC management status of a Wavence device
You can configure the LAC management status of a Wavence device at the node level by selecting the node in the navigation tree Equipment view, and choosing Properties. The Network Element form opens. Click on the System Setting tab and verify the LAC state parameter in the LAC Configuration panel. You can reconfigure the LAC State parameter if required; any changes made at the NE level will only affect that NE.
Note:
-
The LAC configuration parameters are available for configuration only if the LAC management is enabled. See Enable LAC management for more information about enabling LAC management.
-
The NFM-P allows you to unmanage a Wavence device regardless of the LAC status.
If the LAC management state of the node is set to Access Denied, LCT users can request access to the node from an LCT session to NFM-P. When this request is made, a LocalAccessRequest alarm is generated after the specified wait time and appears in the Alarm window.
You can:
-
grant access to the LCT by changing the LAC state to Access Granted.
-
deny access to the LCT by changing the LAC state to Access Denied.
Supported Radio links
Radio links between Wavence devices are autodiscovered by NFM-P. The autodiscovery is supported for the following Radio link types:
-
1+0 radio links; represented by a dashed line on topology maps
-
1+1 radio links; the main link is represented as a dashed green line and the spare links are displayed as dashed blue lines when no alarms exist
After the autodiscovery, NFM-P displays the following parameters on the Radio tab of the Physical Port (Edit) form:
The Radio interface can be:
See the Wavence documentation for a complete list of supported radios.
Radio links between Wavence devices are shown as physical links by NFM-P, with ports as the endpoint type.
To enable Wavence radio link discovery and management, NFM-P requires connectivity between the Wavence NE radio ports, as shown in the following figure. Table 2-1, Connectivity parameter details lists the connectivity parameter details for each supported shelf type.
Figure 2-2: Connectivity example for Wavence radio link discovery and management
Table 2-1: Connectivity parameter details
|
Shelf type |
1-MSS-4 |
2-MSS-4 |
3-MSS-8 |
4-MSS-4 |
|---|---|---|---|---|
|
2-MSS-4 |
PPPRF Enabled LinkID (as assigned) |
— |
PPPRF Enabled LinkID (as assigned) |
— |
|
3-MSS-8 |
PPPRF Enabled LinkID (23, 23) PPPRF Disabled LinkID (26, 26) |
PPPRF Enabled LinkID (as assigned) |
— |
PPPRF Enabled LinkID (11, 11) PPPRF Disabled LinkID (13, 13) PPPRF Disabled LinkID (15, 15) |
To discover multiple radio links, you must provision the radio ports on the Wavence based on the following criteria:
-
Only one radio port can have PPPRF enabled. The far endpoint on the same link must have the same configuration as the first endpoint. PPPRF should be disabled on both endpoints for the second and any subsequent radio links.
- LinkID requirements include:
-
The LinkID must be enabled for all of the port members of the configuration that have the same LINKGRP, and a different LINKMEMBER that matches the far endpoint.
-
Expected and Sent values must be equal (for example, 11, 11 or 13, 13).
-
For a multiple N × (1+x) radio configurations on the same NE, the LINKGRP must be unique without overlapping (for example, 1 and 2).
-
LinkID should be formatted as LINKGRP:LINKMEMBER in a hexadecimal format where LINKGRP is the first character and LINKMEMBER are the members.
-
Any mismatch between the LinkID at the link level (for example, Send is not equal to Expected) mutes the radio connection (MPT case).
-
-
As a requirement for the first radio link to be discovered, the remote address must be present at both endpoints. For subsequent links, alarms cannot be present on the radio port.
-
When radio link aggregation is enabled for any of the radio links between two Wavences, all radio links must belong to the same LAG.
-
When 1+1 configuration is deleted resulting in two 1+0 radio links, NFM-P can display incorrect information for the remote interfaces. The Remote interface for the previously Spare port can be set to the Main port or 0. The incorrect information occurs because the Wavence node sends incorrect values in the transient phase.
-
When the LAG member links are deleted, NFM-P does not update the display of the link. For example, the LAG configuration with links to two members can display as one link or no link even after the two links are deleted. The incorrect information occurs because the Wavence node sets the remote interface to 0 momentarily.
Note: By default, the PPPRF parameter is enabled and dimmed on the NFM-P GUI. Use the Wavence element manager to disable or enable the PPPRF parameter, if required.
When you configure out-of-band management, the PPPRF and LinkID parameters do not need to be enabled for the Wavence, Release 5.2, 6.0, or later. If the PPPRF and LinkID parameters are disabled on all the radio ports, the radio links are still discovered successfully and the criteria 1 and 2 are not applicable.
When you configure in-band management, the 1+0, 1+1 radio links between two Wavence nodes require the PPPRF parameter to be enabled on the radio ports for NFM-P to discover the far end Wavence node. The 2+0, 3+0, 4+0 radio links between two Wavence nodes require the PPRF parameter to be enabled on one of the radio links at both ends. The PPPRF and LinkID parameters need not be enabled for other radio links.
Wavence radio link protection schemes
You can apply Wavence radio link protection by configuring the Protection Type parameter in the Wavence element manager. Additionally, you can switch between an in-service protected radio link and a standby protected link to perform routine maintenance tasks using the Wavence element manager. See the Wavence documentation for more information.
In-service protected radio links are represented as dashed green links on the physical topology map; standby links are shown as dashed blue links; out-of-service radio links, main or spare, are represented as dashed red links. If a mismatch of active and standby states should occur, main links are represented as dashed green links on the Physical topology map; spare links are shown as dashed blue links on expansion.
Note: The status of a protected link does not have a direct impact on the status of a service. See Table 15-4, Wavence service status for more information about the service status.
Wavence backup and restore policy requirements
The NFM-P provides backup and restore functions which are supported on some Wavence devices, provided backup and restore policies have been created and distributed to Wavence nodes. See the NSP Classic Management User Guide for information about configuring policies and using NFM-P backup and restore. This section describes configuration information for Wavence backup and restore policies.
SFTP configuration
Core Evo devices only support software download using SFTP. When configuring SFTP on a policy, the following parameters must be provided:
The SFTP user must have access to the file storage location path. For UBT-SA nodes, the file storage location path must be an absolute path from the / directory. For other nodes, a subjective path can be specified; the root directory for the subjective path is the home directory of the SFTP user.
Note: For nodes other than UBT-SA, if the folder specified in the path does not exist, the SFTP user will attempt to create the required folder structure. The policy may fail if the SFTP user cannot create the folder; for example, a non-administrative user creating a folder in the root directory, or in a location they do not have access to. Ensure that the file storage location exists or that the specified SFTP user has the permission required to create it.
To obtain the host fingerprint, see To determine a host fingerprint for information about NFM-P host fingerprints. Some nodes require a specific signature system, as follows:
-
MSS-E/HE/XE and UBT-NIM nodes, Wavence Release 23A or later, only support using ED25519 fingerprints. Use the following command to obtain the correct fingerprint:
ssh-keygen -E md5 -l -f /etc/ssh/ssh_host_ed25519_key.pub | sed 's/://g' | sed 's/MD5//g'| awk '{print$2}'
Earlier releases and all UBT-SA nodes only support using RSA fingerprints. Use the following command to obtain the correct fingerprint:
ssh-keygen -E md5 -l -f /etc/ssh/ssh_host_rsa_key.pub | sed 's/://g' | sed 's/MD5//g'| awk '{print$2}'
-
MSS-4/8 nodes only support using ECDSA fingerprints. Use the following command to obtain the correct fingerprint:
ssh-keygen -E md5 -l -f /etc/ssh/ssh_host_ecdsa_key.pub | sed 's/://g' | sed 's/MD5//g'| awk '{print$2}'
-
UBT-SA nodes only support using RSA fingerprints. Use the following command to obtain the correct fingerprint:
ssh-keygen -E md5 -l -f /etc/ssh/ssh_host_rsa_key.pub | sed 's/://g' | sed 's/MD5//g'| awk '{print$2}'
Wavence log file retrieval
The NFM-P supports the retrieval of log files stored by the Wavence devices.
The logs include:
-
all user administration operations and the configuration changes in user activity logs in a user readable format. One entry is captured for each user action.
-
all the security-related events in a security audit trail. These events include all security-related settings changes, user accounts management, exporting audit logs, and user login attempt failure.
Three types of log files are stored:
Log file compression
You can use the File Compression parameter on the Log Retrieval configuration form (Administration→NE Maintenance→Log Retrieval) to compress log files before storing. The following compression options are supported: none, ZIP, and GZIP.
See To retrieve log files stored by Wavence devices for more information about retrieving logs.