When routers are rebooted, existing RTT Tests created with the Data Aggregator REST API feature are removed from the device

Document ID : KB000013718
Last Modified Date : 14/02/2018
Show Technical Document Details
Introduction:

 

With the Data Aggregator REST API we can configure RTT Tests from CA Performance Management directly on the routers.
However, one may notice that when the routers are reloaded/rebooted for any reason (for example maintenance), the RTT Tests previously created and discovered by CA Performance Management are removed on the device. And their related Component Items in CA Performance Center are changing status to "Not Present".  

These Tests are not automatically recreated by CA Performance Management and their Items are not reused when the router is restarted.

Some customer may notice this behavior is different to what CA eHealth does in similar situation. CA eHealth recreates the Tests on the router after the reboot and reuse the existing RTT elements previously discovered.
 

Question:

 

Is it the expected behavior that when routers are rebooted, the existing RTT Tests configured on the device with the Data Aggregator REST API are removed, and are not automatically recreated by CA Performance Management, as well as their Component Items previously discovered are not reused in CA Performance Management?

 

Answer:



This is the expected behavior in CA Performance Management. In Data Aggregator, creating RTT Tests with the Data Aggregator REST API means configuring the Tests on the target router via SNMP "SET" calls. 

Nothing related to the Test is stored on the Data Aggregator. We will have an entry about what has been wrote to the device to create the Test, but we don't create a Test item in the database so we can write it again later. 
We will read the Test during Change Detection for some info, create the Component and then collect performance metrics, but we are not storing the entire Test makeup anywhere. The RTT Test must exist on the device for us to poll it. 
We only read what the Vendor Certification allows to poll on the device for the supported metrics.

With the Data Aggregator REST API we set the MIB variable “rttMonCtrlAdminNvgen” to the value "true"; this way the Tests are written to the router’s running config and users can save the running config to NVRAM (startup config), which is persistent.
User must manually save running config to startup config on the router to preserve Tests across router’s restart.

Saving the running config to the startup config allows to keep all the Tests after the router's reload.  
 
 


Additional Information:

 

CA Performance Management is designed to just read the current Tests on the device and collect data on them. We added the ability to create Tests from CA Performance Management directly to the device using the Data Aggregator REST API; but we don't store the Test configuration in CA Performance Management.

When the RTT Tests are in the router’s running config (which is non-persistent) and the device is rebooted, all the Tests would be lost.

With the Data Aggregator REST API we set the SNMP MIB variable “rttMonCtrlAdminNvgen” to true, so that the Tests are written to the router’s running config; this is the way to allow users to save the running config to the NVRAM (startup config), which is persistent.

When the rttMonCtrlAdminNvgen MIB variable is set to true, its associated operation is shown in the output of the show running command and therefore can be saved in “nonvolatile memory (NVRAM)”. The default value for variable rttMonCtrlAdminNvgen is false.
Setting this variable to true alone doesn't mean it's persistent, it means Test can be made persistent by the user.  If false, user will never be able to make the Test persistent.

User must manually save running config to NVRAM startup config to preserve Tests across router’s restart. 
 
 
On CA Performance Center, these RTT Test items should show missing statistics data only during the router reload time. After that the Items will shows data again.