Feature Summary and Revision History

Feature Description

CPS now supports a process restart event whenever qns process is restarted on the system.

To support this, a new alarm ProcessRestarted is introduced.

CPS must send process restarted snmp traps whenever qns process gets restarted on the system.

For more information, see the following sections:

• Application Notifications table in the CPS SNMP, Alarms, and Clearing Procedures Guide

• Clearing Procedures chapter in the CPS SNMP, Alarms, and Clearing Procedures Guide

• Testing Traps Generated by CPS in the CPS Troubleshooting Guide

Feature Summary and Revision History

Feature Description

CPS now supports holding the alarms when NMS is down or unreachable and sends the alarms to NMS once it is reachable.

If NMS is not available, the alarms are stored in Admin DB (DB Name: CPSAlarmResync, collection names: CpsCompAlarm, CpsAppAlarm) and sent only when the NMS is up.

To support this, a new parameter, alarm_resync_enabled has been added in Configuration.csv file. By default, the value is false.

Note	Currently, alarm synchronization is supported only for VMware environment.

• When alarm_resync feature is enabled:

  • If NMS is up, the NMS receives all the alarms.

  • If NMS is down, NMS does not receive any alarms.

    The alarms are stored in alarm database. Once the NMS is in reachable state, all the alarms stored in alarm database are forwarded to NMS.

• When alarm_resync feature is disabled:

  • If NMS is up/down, the alarms are forwarded to NMS without checking NMS server’s availability.

  • If alarm_resync feature is disabled after having been enabled for sometime.

    Any older alarms stored in alarm database are forwarded to NMS without checking its reachability.

    New alarms generated from all VMs are forwarded to NMS without checking its reachability.

For more information, see General Configuration Parameters table in the CPS Installation Guide for VMware.

Memory and Performance Impact

• If the alarms frequency increases while NMS is down, then additional disk space is required in Session Manager VMs.

• Once NMS is reachable, alarms are forwarded to NMS server sequentially from active Policy Director (LB). This can result in performance impact on the Policy Director (LB) VM.

Limitations

• If critical trap is generated for particular alarm while alarm resync feature is enabled and NMS is UP, the alarm is forwarded to NMS. After sometime when NMS is down and clear trap is generated for the same alarm, the clear alarm does not get stored in alarm database (critical alarms only get inserted into alarm database) and is not sent to NMS. When NMS is UP, the feature sends the existing active alarms to NMS. In such cases, the NMS misses the clear alarm for the critical alarm already received.

• If alarm_resync feature is disabled after enabled, existing alarms stored in database while NMS is down is forwarded to NMS without checking its reachability to avoid stale alarms. This is done to maintain in-order delivery of alarms to NMS. If the alarm_resync feature stores alarms even after feature is disabled, there is a possibility of new alarms reaching the NMS before alarm_resync feature sends the alarms stored in database to NMS. To avoid such stale alarm scenarios, alarm_resync feature sends out the alarms to NMS immediately when it is disabled.

• VirtualInterfaceDown, VirtualInterfaceUp: This particluar alarm for internalvip (lbvip02) is not stored in AlarmResync DB. This alarm is sent directly from gen_noti_to_nms function to NMS server.

Feature Summary and Revision History

Feature Description

CPS now supports SRIOV interface on CPS VMs with XL710 Intel NIC interface. It also supports bonding on SRIOV VFs on guest VM.

• If all the guest VM interfaces are SR-IOV interface then ifrename.yaml is not required.

• If multiple drivers are used, then ifrename.yaml file must be updated with corresponding driver. For example, I40evf for XL710

• Bonding can be created on two different virtual functions. The virtual functions can be created from same physical function or different physical function in the host based on the requirements.

Note	Currently, SR-IOV is only supported for OpenStack deployments. SR-IOV interface is supported only in fresh deployment since all the VMs need to redeployed with new network and interface configured.

For more information, see SR-IOV Support section in the CPS Installation Guide for OpenStack.