Upload not reflecting in SNTC Portal - BR

[cisco]

Hello,

A new collection was performed on one of our clients with CSPC on July 14, the data was verified and correct, but at the end of the upload in the SNTC Portal it was verified that the information is not the same. Could check for backend processing failure
Adjustments were made to the timeout value in the CSPC settings, since it was not collecting information from ip phones in some exchanges, after the change the collection worked, but this information is not appearing on the portal.

I thank the attention.

[Cheri Fairbrother]

Hi there,

Thank you for your question. We will have an expert review and respond to you just as soon as possible.

Cheers,
Cheri

[Suchita Shewale]

Hi There,

I see that the upload from Jul 14th was received and reported as processed successfully on the portal. Are you seeing issues with IP Phones reporting on the portal? Could you please send me private message with IP address of Call manager/IP Phones that has issue?  Steps to send private message are here

I am sorry if I did not quite understand your issue.

Regards, Suchita

[Suchita Shewale]

Hi There, I have received the private message and am currently analyzing the issue. We will get back as soon as we are able to find the root cause.

Regards

[CC Cisco]

Hello,

Can you please share the following with us from the collector?

*Click on Collected Data -> View Data -> Select Dataset.

*Check for all the call managers, the value for the following Dataset: CISCO_CCM_MIB_ccm

*Share a screenshot of the ones with missing phones vs the ones showing phones. We need to see if data is being collected.

Regards,

Cesar

[cisco]

Dear Cesar, please follow the requested information.

Best Regards.

William Resende

[CC Cisco]

Hello William,

Thanks for sharing this information. Based on the screenshot, it appears that some data is not being picked up due to potentially a timeout error.

Please try increasing the timeout value of the SNMP version that you are using. It's probably safe to just double the value.

This can be changed on Settings -> Inventory Settings -> Global Timeouts.

Here is an example of SNMPv2c:

Following this, please execute a new inventory and verify if the same dataset is now being populated.

Please post back the results.

Regards,

Cesar

[cisco]

Dear Cesar, even increasing the timeout did not collect the information.

Best Regards.

William Resende

[CC Cisco]

Good morning William,

Then there is a good chance that the call managers themselves are failing to return data to the SNMP request from the collector.

My recommendation is the following:

• Log into CLI with collectorlogin user and perform an SNMPwalk to the following OID and see if data is being returned.

The OID is: 1.3.6.1.4.1.9.9.156.1.1.2.1

• If no data, then it's possible that you will need to work with the CUCM TAC support team to address the issue as the SNTC portal expects this data to be present to be able to process the inventory.

Regards,

Cesar

[cisco]

Hello Dear Cesar,

I tested the OID 1.3.6.1.4.1.9.9.156.1.1.2.1 on the four servers and two nodes that are not presented the information of the devices do not respond, in this case can be a block in the Firewall? I also tested the settings and left the SNMP Master Agent services, it still is not working, do you have any other suggestions?

Best Regards.

William Resende

Log:

[collectorlogin@localhost ~]$ snmpwalk -Os -c sntcv2 -v 2c 10.10.XXX.XXX 1.3.6.1.4.1.9.9.156.1.1.2.1
enterprises.9.9.156.1.1.2.1.2.1 = STRING: "SLZIPBX"
enterprises.9.9.156.1.1.2.1.2.2 = STRING: "BSBIPBX"
enterprises.9.9.156.1.1.2.1.2.3 = STRING: "SSAIPBX"
enterprises.9.9.156.1.1.2.1.2.4 = STRING: "BHZIPBX"
enterprises.9.9.156.1.1.2.1.3.1 = STRING: "Subscriber"
enterprises.9.9.156.1.1.2.1.3.2 = STRING: "Publisher"
enterprises.9.9.156.1.1.2.1.3.3 = STRING: "Subscriber"
enterprises.9.9.156.1.1.2.1.3.4 = STRING: "Subscriber"
enterprises.9.9.156.1.1.2.1.4.1 = STRING: "UNKNOWN"
enterprises.9.9.156.1.1.2.1.4.2 = STRING: "10.5.1.11901-1"
enterprises.9.9.156.1.1.2.1.4.3 = STRING: "UNKNOWN"
enterprises.9.9.156.1.1.2.1.4.4 = STRING: "UNKNOWN"
enterprises.9.9.156.1.1.2.1.5.1 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.5.2 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.5.3 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.5.4 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.6.1 = INTEGER: 1
enterprises.9.9.156.1.1.2.1.6.2 = INTEGER: 1
enterprises.9.9.156.1.1.2.1.6.3 = INTEGER: 1
enterprises.9.9.156.1.1.2.1.6.4 = INTEGER: 1
enterprises.9.9.156.1.1.2.1.7.1 = Hex-STRING: 0A 14 2F FD
enterprises.9.9.156.1.1.2.1.7.2 = Hex-STRING: 0A 0A 2F FD
enterprises.9.9.156.1.1.2.1.7.3 = Hex-STRING: 0A 1E 2F FD
enterprises.9.9.156.1.1.2.1.7.4 = Hex-STRING: 0A 28 2F FD
enterprises.9.9.156.1.1.2.1.8.1 = STRING: "StandAloneCluster"
enterprises.9.9.156.1.1.2.1.8.2 = STRING: "StandAloneCluster"
enterprises.9.9.156.1.1.2.1.8.3 = STRING: "StandAloneCluster"
enterprises.9.9.156.1.1.2.1.8.4 = STRING: "StandAloneCluster"
enterprises.9.9.156.1.1.2.1.9.1 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.9.2 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.9.3 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.9.4 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.10.1 = ""
enterprises.9.9.156.1.1.2.1.10.2 = ""
enterprises.9.9.156.1.1.2.1.10.3 = ""
enterprises.9.9.156.1.1.2.1.10.4 = ""
[collectorlogin@localhost ~]$ snmpwalk -Os -c sntcv2 -v 2c 10.20.XXX.XXX 1.3.6.1.4.1.9.9.156.1.1.2.1
enterprises.9.9.156.1.1.2.1.2.1 = STRING: "SLZIPBX"
Timeout: No Response from 10.20.47.253
[collectorlogin@localhost ~]$ snmpwalk -Os -c sntcv2 -v 2c 10.30.XXX.XXX1.3.6.1.4.1.9.9.156.1.1.2.1
Timeout: No Response from 10.30.47.253
[collectorlogin@localhost ~]$ snmpwalk -Os -c sntcv2 -v 2c 10.40.XXX.XXX 1.3.6.1.4.1.9.9.156.1.1.2.1
enterprises.9.9.156.1.1.2.1.2.1 = STRING: "SLZIPBX"
enterprises.9.9.156.1.1.2.1.2.2 = STRING: "BSBIPBX"
enterprises.9.9.156.1.1.2.1.2.3 = STRING: "SSAIPBX"
enterprises.9.9.156.1.1.2.1.2.4 = STRING: "BHZIPBX"
enterprises.9.9.156.1.1.2.1.3.1 = STRING: "Subscriber"
enterprises.9.9.156.1.1.2.1.3.2 = STRING: "Publisher"
enterprises.9.9.156.1.1.2.1.3.3 = STRING: "Subscriber"
enterprises.9.9.156.1.1.2.1.3.4 = STRING: "Subscriber"
enterprises.9.9.156.1.1.2.1.4.1 = STRING: "UNKNOWN"
enterprises.9.9.156.1.1.2.1.4.2 = STRING: "UNKNOWN"
enterprises.9.9.156.1.1.2.1.4.3 = STRING: "UNKNOWN"
enterprises.9.9.156.1.1.2.1.4.4 = STRING: "10.5.1.11901-1"
enterprises.9.9.156.1.1.2.1.5.1 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.5.2 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.5.3 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.5.4 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.6.1 = INTEGER: 1
enterprises.9.9.156.1.1.2.1.6.2 = INTEGER: 1
enterprises.9.9.156.1.1.2.1.6.3 = INTEGER: 1
enterprises.9.9.156.1.1.2.1.6.4 = INTEGER: 1
enterprises.9.9.156.1.1.2.1.7.1 = Hex-STRING: 0A 14 2F FD
enterprises.9.9.156.1.1.2.1.7.2 = Hex-STRING: 0A 0A 2F FD
enterprises.9.9.156.1.1.2.1.7.3 = Hex-STRING: 0A 1E 2F FD
enterprises.9.9.156.1.1.2.1.7.4 = Hex-STRING: 0A 28 2F FD
enterprises.9.9.156.1.1.2.1.8.1 = STRING: "StandAloneCluster"
enterprises.9.9.156.1.1.2.1.8.2 = STRING: "StandAloneCluster"
enterprises.9.9.156.1.1.2.1.8.3 = STRING: "StandAloneCluster"
enterprises.9.9.156.1.1.2.1.8.4 = STRING: "StandAloneCluster"
enterprises.9.9.156.1.1.2.1.9.1 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.9.2 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.9.3 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.9.4 = INTEGER: 2
enterprises.9.9.156.1.1.2.1.10.1 = ""
enterprises.9.9.156.1.1.2.1.10.2 = ""
enterprises.9.9.156.1.1.2.1.10.3 = ""
enterprises.9.9.156.1.1.2.1.10.4 = ""
[collectorlogin@localhost ~]$

[CC Cisco]

Hi William,

The only thing I can think is to pass the "-t" flag to your snmpwalk and try very high values in case it really is a timeout issue.

This would not be a firewall issue as you seem to be capturing data for other MIBs.

The best thing to do next is to request support with the CUCM support team or support community as this falls beyond my area of expertise. This issue seems to be on the call managers themselves.

Regards,

Cesar