interface_traffic not creating QoS data

Document ID : KB000033561
Last Modified Date : 14/02/2018
Show Technical Document Details
interface_traffic not creating QoS data

1) No QOS data for some profiles in interface_traffic
2) SLA report not working as expected due to the data issues

- Check that the probe is generating the given QOS data
- Check that the remote/secondary hub or tunnel is NOT queuing the data
- Make sure the queues across all tiers are defined properly and that the data is moving to its destination

- Check that the data_engine at loglevel 15 shows whether or not the data is being INSERTed into the correct RN_QOS_DATA_XXXX table and that the tableids are the tableids that are expected and that they have 'current' QOS data.

data_engine log reference note:
Oct 21 07:13:30:096 [8100] de: QoSInsert::AddQoSObjectToMaps - table=1996542 qos=QOS_INTERFACE_TRAFFIC source=PL-2960-48S-2 target=IN-Gi1/0/49 metric= Complete: yes

Note that above entry is NOT a QOS insert of data. That entry is from the log when it runs through its routines at startup so you'll have to wait for that to finish before you can tell if the expected QoS data is being INSERTed into the expected database table.

Check QOS object Properties in the SLM portlet under probes view (interface_traffic) and use the black button to view the QoS object properties and identify the table/tableids.

select * from s_qos_data where source = '<interface_traffic_profile/device_with_no_data>' and target like '<QOS_target_where_there is no current data>'

select * from s_qos_data where source = 'Whip_plaza1_2960_E' and target = 'IN-Gi1/0/49' and qos = 'QOS_INTERFACE_TRAFFIC'

Identify the tableid

select * from RN_QOS_DATA_0015 where tableid = 1619593

showed NO QoS data being saved based on that tableid reference.

Check the tableids where the current data is being stored as per the data_engine log at loglevel 15 (where the INSERTS are occurring)

If the data is being stored in 'newer' tableids you have to either update the tableids or delete the old data. See below.

select * from s_qos_data where source = '<interface_traffic_profile/device_with_no_data>' and target like '%IN-Gi1/0/49%' and qos = 'QOS_INTERFACE_TRAFFIC'

As it turns out from investigation in this case, there was no data in the RN_QOS_DATA_0015 table for the given (older) tableids.

To compare all of the data and in this case the targets in the old and new tableids run the query:

select * from s_qos_data where table_id in (<old_table_id>, <new_table_id>)


select * from s_qos_data where table_id in (1619594, 1922229)

***We found that the old targets were named

IN-Gi1/0/49 but the NEW targets were longer and named IN-GigabitEthernet1/0/49

For the outbound, we also found similar changes:

OUT-Gi1/0/49 (old)
OUT-GigabitEthernet1/0/49 (new)

This occurred months ago as per the sampletime's in the tables queried.

In some cases if the data referenced by the old tableids still have data and the data_engine hasnt deleted it yet through maintenance, you could run:

UPDATE RN_QOS_DATA_0015 SET table_id = <new_table_id> WHERE table_id = <old_table_id>

UPDATE RN_QOS_DATA_0015 SET table_id = 1922228 WHERE table_id = 1619593

Note that the table id 1922228 corresponded to the new INBOUND target and 1922229 corresponded to the new OUTBOUND target.

--This would move all the "old" data to the new table_id - then wipe the "bad" rows from S_QOS_DATA

BUT in our case the old data was gone but the QoS objects (as displayed in the SLM) were still using the old table_ids.

So once all of the above work has been completed identifying the new and old table ids and whether or not there is historical data in the HN tables,


- deactivate the data_engine
- deactivate the interface traffic probe

select * from rn_qos_data_0015 where table_id = 1922229 order by sampletime DESC

***Check the data in the columns and see if there is an attribute you can use to remove the bad rows. In our case it was ci_metric_id because ALL of the ci_metric_ids that corresponded to the OLD tableid were NULL.

Drag and drop the ci_metric_id columns over to the left to compare it against the table_ids to be sure BEFORE you run any deletes. For example run the select to confirm the resultant set of data:

select * from s_qos_data where source = 'Whip_Plaza2_2960_B' and qos like 'QOS_INTERFACE_TRAFFIC%'

Then the delete to resolve the core issue:

delete from s_qos_data where source = 'Whip_Plaza2_2960_B' and qos like 'QOS_INTERFACE_TRAFFIC%' and ci_metric_id is NULL

If you check the SLM QoS object again in the SLM portlet you will see that the old targets are gonr and the new targets remain and contain data when you display the graph.

Then if this data is being used in an SLA (as it was in this case), you will have to open up the SLA and run though editing each target to correct it (select and use the new target definition) then close the window to save the SLA. The report should then be corrected.

Don't forget change the data_engine loglevel back to 3 from 15 otherwise you may run out of disk space. Enable the data_engine and interface_traffic probes.

keywords: no longer any data probe interface_traffic interface interfaces SLA report empty inaccurate target changes changed reports