This section applies in the case where the Rhino VoLTE TAS SGC has previously received its initial configuration and only the SNMP subsystem requires reconfiguration.

Warning

If other SGC configuration has changed it is necessary to follow the Reconfiguring the SGC procedure.
Warning

Reconfiguring the SNMP subsystem will cause an SNMP outage in live deployments. This includes other SNMP services, such as Rhino and Initconf. Full SNMP service will resume once the procedure is complete.

There are three situations where the SGC’s SNMP subsystem may require reconfiguring:

SNMP reconfiguration without upgrade or rollback

This process should be followed when the SGC SNMP subsystem requires reconfiguration. It consists of two phases:

  1. Removal of existing SNMP configuration.

  2. Application of desired SNMP configuration.

For each affected node type (SGC or SMO) the steps to follow are:

  1. Complete Preparation for SGC SNMP reconfiguration.

  2. Modify the snmp-config.yaml to the desired final state and upload the modified configuration using rvtconfig.

Upgrading when SNMPv3 is enabled

Warning

This process is only required when both:

  • SNMPv3 is enabled; and

  • Upgrading from VM version 4.0.0-23-1.0.0 or older to VM version 4.0.0-24-1.0.0 or newer.

The process consists of two phases:

  1. Preparation and removal of the existing SNMP configuration.

  2. Performing the upgrade.

For each affected node type (SGC or SMO) the steps to follow are:

  1. Complete Preparation for SGC SNMP reconfiguration.

  2. Continue with the upgrade procedure, ensuring that the uplevel SNMP configuration reflects the desired final state. No additional steps are required; SNMP will automatically be configured and enabled as the nodes are upgraded.

Rolling back when SNMPv3 is enabled

Warning

This process is only required when both:

  • SNMPv3 is enabled; and

  • Rolling back from VM version 4.0.0-24-1.0.0 or newer to VM version 4.0.0-23-1.0.0 or older.

The process consists of two phases:

  1. Preparation and removal of the existing SNMP configuration.

  2. Performing the rollback.

For each affected node type (SGC or SMO) the steps to follow are:

  1. Complete Preparation for SGC SNMP reconfiguration

  2. Then, continue with the rollback procedure, ensuring that the downlevel SNMP configuration reflects the desired final state. No additional steps are required; SNMP will automatically be configured and enabled as the nodes are rolled back.

Preparation for SGC SNMP reconfiguration

This step is common to all SGC SNMP reconfiguration processes and must only be followed when directed by those processes. This step removes the existing SNMP configuration from the SGC in preparation for a new configuration.

Warning

Reconfiguring the SNMP subsystem will cause a full SNMP outage in live deployments for the affected node type. This includes other services that provide SNMP agents and notifications, such as Rhino and Initconf.

For the node type being prepared, the steps to follow are:

  1. Ensure that you have a backup copy of the active cluster’s original snmp-config.yaml configuration file.

  2. Modify the active cluster’s snmp-config.yaml to disable all SNMP:

    deployment-config:snmp:
  v1-enabled: false
  v2c-enabled: false
  v3-enabled: false

  3. Upload the modified configuration using rvtconfig and wait for Initconf to converge.

  4. Remove the SGC’s existing SNMP configuration.

Remove the SGC’s existing SNMP configuration

Note

Perform this process once, on one VM of the type being reconfigured. The process affects the whole SGC cluster.
Tip

When performed as part of a rollback operation this process may be performed on any uplevel or downlevel cluster member where Initconf has successfully converged (i.e. "gone Green").

Either the automatic or manual method may be used.

Automatic

The sgc_snmp_cleaner tool is included on newer VMs by default at /opt/tasvmruntime-py/bin/sgc_snmp_cleaner. If not present on your VM, request it from your support representative and follow the installation instructions provided with it.

It must be executed on an active VM in the cluster to be reconfigured

[sentinel@tst-smo-1 ~]$ /opt/tasvmruntime-py/bin/sgc_snmp_cleaner --deployment-id tst
Checking the output

The script will report on the SNMP nodes, SNMP targets and USM users that it finds and removes. Successful completion will indicate:

SNMP configuration successfully cleared

Unsuccessful completion may indicate one of the following:

  • USM user configuration still exists:

  • Target address configuration still exists:

  • SNMP node configuration still exists:

Example successful output from the script for a single node test cluster:

[sentinel@tst-smo-1 ~]$ PYTHONPATH=/opt/tasvmruntime-py/lib/python3.7/site-packages/ python3 sgc_snmp_cleaner.py --deployment-id tst
Found SNMP node: tst-smo-1_v2c
  - Removed SNMP node: tst-smo-1_v2c
Found SNMP node: tst-smo-1_v3
  - Removed SNMP node: tst-smo-1_v3
Found SNMP target: 172.30.102.143#162#v3#UdpIpv4#trap#v3user
  - Removed SNMP target: 172.30.102.143#162#v3#UdpIpv4#trap#v3user
Found SNMP target: 172.30.102.143#162#v2c#UdpIpv4#trap#tst
  - Removed SNMP target: 172.30.102.143#162#v2c#UdpIpv4#trap#tst
Found USM user: snmp_user
  - Removed USM user: snmp_user
SNMP configuration successfully cleared

In the event that execution is unsuccessful follow the manual procedure.

Manual

  1. Log into one VM of the type being reconfigured.

  2. Start the SGC CLI: /home/sentinel/ocss7/<deployment_id>/<deployment_id>-<node_id>/current/cli/sgc-cli.sh

  3. Then, view the configured SNMP nodes by executing the SGC CLI command display-snmp-node.

    172.30.102.140:55555 tst-smo-1> display-snmp-node:
Found 3 object(s):
+--------------+----------+--------+--------+---------------+---------------+---------------+----------+--------------+---------------+--------+
|oname         |dependenci|enabled |active  |node           |transport-type |host           |port      |snmp-version  |community      |extended|
|              |es        |        |        |               |               |               |          |              |               |-traps  |
+--------------+----------+--------+--------+---------------+---------------+---------------+----------+--------------+---------------+--------+
|tst-smo-1_v3  |0         |true    |true    |tst-smo-1      |UDP            |172.30.102.140 |11103     |v3            |tst            |true    |
+--------------+----------+--------+--------+---------------+---------------+---------------+----------+--------------+---------------+--------+
|tst-smo-2_v3  |0         |true    |true    |tst-smo-2      |UDP            |172.30.102.141 |11103     |v3            |tst            |true    |
+--------------+----------+--------+--------+---------------+---------------+---------------+----------+--------------+---------------+--------+
|tst-smo-3_v3  |0         |true    |true    |tst-smo-3      |UDP            |172.30.102.142 |11103     |v3            |tst            |true    |
+--------------+----------+--------+--------+---------------+---------------+---------------+----------+--------------+---------------+--------+

    For each line in the returned table, execute the following two SGC CLI commands to disable and remove those nodes:

    • disable-snmp-node: oname=<oname>

    • remove-snmp-node: oname=<oname>

      For instance:

      172.30.102.140:55555 tst-smo-1> disable-snmp-node: oname=tst-smo-1_v3
OK snmp-node disabled.
172.30.102.140:55555 tst-smo-1> remove-snmp-node: oname=tst-smo-1_v3
OK snmp-node removed.

  4. Similarly, view the configured SNMP notification targets by executing the SGC CLI command display-target-address. For each line in the returned table, execute remove-target-address: oname=<oname>.

  5. Finally, view the configured SNMP USM users by executing the SGC CLI command display-usm-user. For each line in the returned table, execute remove-usm-user: oname=<oname>.

  6. Check that no SNMP configuration remains by executing the following commands and verifying that there are no lines in the returned tables.

    • display-snmp-node

    • display-target-address

    • display-usm-user

      For instance:

      172.30.102.140:55555 tst-smo-1> display-snmp-node
Found 0 objects.

172.30.102.140:55555 tst-smo-1> display-target-address:
Found 0 objects.

172.30.102.140:55555 tst-smo-1> display-usm-user:
Found 0 objects.

In the event that manual cleanup is unsuccessful please contact your support representative.

Previous page Next page
Rhino VoLTE TAS Version 4.2