Request for help on monitoring CPU and Memory of Cisco NCS 5500

[wyang]

Hello,

Cisco NCS 5500 routers running IOS XR are monitored on our Zabbix server using "Template Net Cisco IOS SNMPv2", with which neither router CPU nor Memory is discovered.

I'd much appreciate if you could share your template for monitoring CPU and memory of Cisco NCS 5500. Thanks very much in advance.

[wyang]

On Cisco KB https://community.cisco.com/t5/netwo...-hId-113636207, it is recommended to use the following OIDs in the CISCO-ENHANCED-MEMPOOL-MIB for the memory monitoring of Cisco NCS 5500
• cempMemPoolHCUsed 1.3.6.1.4.1.9.9.221.1.1.1.1.18
• cempMemPoolHCFree 1.3.6.1.4.1.9.9.221.1.1.1.1.20

I'd much appreciated if any one could help me on how to set up a discovery rule and how to created item prototypes for cempMemPoolHCUsed/cempMemPoolHCFree. Greatly appreciated.

snmpwalk results are as follows

.1.3.6.1.4.1.9.9.221.1.1.1.1.2.11.1 = INTEGER: 2
.1.3.6.1.4.1.9.9.221.1.1.1.1.2.11.2 = INTEGER: 11
.1.3.6.1.4.1.9.9.221.1.1.1.1.2.11.3 = INTEGER: 12
.1.3.6.1.4.1.9.9.221.1.1.1.1.2.13.1 = INTEGER: 2
.1.3.6.1.4.1.9.9.221.1.1.1.1.2.13.2 = INTEGER: 11
.1.3.6.1.4.1.9.9.221.1.1.1.1.2.13.3 = INTEGER: 12
.1.3.6.1.4.1.9.9.221.1.1.1.1.3.11.1 = STRING: "processor"
.1.3.6.1.4.1.9.9.221.1.1.1.1.3.11.2 = STRING: "reserved"
.1.3.6.1.4.1.9.9.221.1.1.1.1.3.11.3 = STRING: "image"
.1.3.6.1.4.1.9.9.221.1.1.1.1.3.13.1 = STRING: "processor"
.1.3.6.1.4.1.9.9.221.1.1.1.1.3.13.2 = STRING: "reserved"
.1.3.6.1.4.1.9.9.221.1.1.1.1.3.13.3 = STRING: "image"
.1.3.6.1.4.1.9.9.221.1.1.1.1.5.11.1 = INTEGER: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.5.11.2 = INTEGER: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.5.11.3 = INTEGER: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.5.13.1 = INTEGER: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.5.13.2 = INTEGER: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.5.13.3 = INTEGER: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.6.11.1 = INTEGER: 1
.1.3.6.1.4.1.9.9.221.1.1.1.1.6.11.2 = INTEGER: 1
.1.3.6.1.4.1.9.9.221.1.1.1.1.6.11.3 = INTEGER: 1
.1.3.6.1.4.1.9.9.221.1.1.1.1.6.13.1 = INTEGER: 1
.1.3.6.1.4.1.9.9.221.1.1.1.1.6.13.2 = INTEGER: 1
.1.3.6.1.4.1.9.9.221.1.1.1.1.6.13.3 = INTEGER: 1
.1.3.6.1.4.1.9.9.221.1.1.1.1.7.11.1 = Gauge32: 196739072
.1.3.6.1.4.1.9.9.221.1.1.1.1.7.11.2 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.7.11.3 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.7.13.1 = Gauge32: 3591634944
.1.3.6.1.4.1.9.9.221.1.1.1.1.7.13.2 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.7.13.3 = Gauge32: 4194304
.1.3.6.1.4.1.9.9.221.1.1.1.1.8.11.1 = Gauge32: 3998687232
.1.3.6.1.4.1.9.9.221.1.1.1.1.8.11.2 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.8.11.3 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.8.13.1 = Gauge32: 604663808
.1.3.6.1.4.1.9.9.221.1.1.1.1.8.13.2 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.8.13.3 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.17.11.1 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.17.11.2 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.17.11.3 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.17.13.1 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.17.13.2 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.17.13.3 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.18.11.1 = Counter64: 196788224
.1.3.6.1.4.1.9.9.221.1.1.1.1.18.11.2 = Counter64: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.18.11.3 = Counter64: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.18.13.1 = Counter64: 3591491584
.1.3.6.1.4.1.9.9.221.1.1.1.1.18.13.2 = Counter64: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.18.13.3 = Counter64: 4194304
.1.3.6.1.4.1.9.9.221.1.1.1.1.19.11.1 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.19.11.2 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.19.11.3 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.19.13.1 = Gauge32: 2
.1.3.6.1.4.1.9.9.221.1.1.1.1.19.13.2 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.19.13.3 = Gauge32: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.20.11.1 = Counter64: 3998695424
.1.3.6.1.4.1.9.9.221.1.1.1.1.20.11.2 = Counter64: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.20.11.3 = Counter64: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.20.13.1 = Counter64: 9194614784
.1.3.6.1.4.1.9.9.221.1.1.1.1.20.13.2 = Counter64: 0
.1.3.6.1.4.1.9.9.221.1.1.1.1.20.13.3 = Counter64: 0


Table in the MIB

cempMemPoolEntry OBJECT-TYPE

SYNTAX CempMemPoolEntry

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"An entry in the memory pool monitoring table."

INDEX {

entPhysicalIndex,

cempMemPoolIndex

}

::= { cempMemPoolTable 1 }

CempMemPoolEntry ::= SEQUENCE {

cempMemPoolIndex CempMemPoolIndex,

cempMemPoolType CempMemPoolTypes,

cempMemPoolName SnmpAdminString,

cempMemPoolPlatformMemory AutonomousType,

cempMemPoolAlternate CempMemPoolIndexOrNone,

cempMemPoolValid TruthValue,

cempMemPoolUsed Gauge32,

cempMemPoolFree Gauge32,

cempMemPoolLargestFree Gauge32,

cempMemPoolLowestFree Gauge32,

cempMemPoolUsedLowWaterMark Gauge32,

cempMemPoolAllocHit Counter32,

cempMemPoolAllocMiss Counter32,

cempMemPoolFreeHit Counter32,

cempMemPoolFreeMiss Counter32,

cempMemPoolShared Gauge32,

cempMemPoolUsedOvrflw Gauge32,

cempMemPoolHCUsed CounterBasedGauge64,

cempMemPoolFreeOvrflw Gauge32,

cempMemPoolHCFree CounterBasedGauge64,

cempMemPoolLargestFreeOvrflw Gauge32,

cempMemPoolHCLargestFree CounterBasedGauge64,

cempMemPoolLowestFreeOvrflw Gauge32,

cempMemPoolHCLowestFree CounterBasedGauge64,

cempMemPoolUsedLowWaterMarkOvrflw Gauge32,

cempMemPoolHCUsedLowWaterMark CounterBasedGauge64,

cempMemPoolSharedOvrflw Gauge32,

cempMemPoolHCShared CounterBasedGauge64

}

[wyang]

Any recommendations would be much appreciated.

[gert.derouck]

Hi Wyang,
in the snmp discoveries i'm using, there's only 1 index. I'm not sure that the discovery will work with 2 indexes as seen in your snmpwalk...

you can try the following:

1. Create new discovery rule:
Type: SNMPv2 agent
SNMP OID: discovery[{#CEMPMEMPOOLTYPE}, .1.3.6.1.4.1.9.9.221.1.1.1.1.3]
Optional -> Filters: {#CEMPMEMPOOLTYPE} matches processor

2. Create item prototypes:
Name: cempMemPoolHCUsed [{#SNMPINDEX}]
Type: SNMPv2 agent
Key: cempMemPoolHCUsed[{#SNMPINDEX}]
SNMP OID: .1.3.6.1.4.1.9.9.221.1.1.1.1.18.{#SNMPINDEX}

Name: cempMemPoolHCFree [{#SNMPINDEX}]
Type: SNMPv2 agent
Key: cempMemPoolHCFree[{#SNMPINDEX}]
SNMP OID: .1.3.6.1.4.1.9.9.221.1.1.1.1.20.{#SNMPINDEX}

Regards

[wyang]

Hi gert.derouck,

I am very appreciative for your kind help. It works perfectly, took hours to get these items being discovered though, which is an known outcome since Zabbix proxies being deployed in containers. Thank you very much.

I have two related confusions on number of indexes. For clarification, each number between two dots in an OID is referred as a field in an SNMP OID in my following questions.

First of all, with the discovery rule you recommended, the items being monitored are cempMemPoolHCFree [11.1], cempMemPoolHCFree [13.1], cempMemPoolHCUsed [11.1], and cempMemPoolHCUsed [13.1]. It looks to me that the {#SNMPINDEX} are 11.1 and 13.1, while "11.1" and "13.1" containing two indexes with the less significant field having a same value. Please correct me.

Secondly, does your term "in the snmp discoveries i'm using, there's only 1 index" means only 1 field is allowed to be a variable in an SNMP OID in a discovery rule, while the field is not necessarily to be the last field in an SNMP OID?

Thank you very much!

[gert.derouck]

I just meant that in my active snmp discovery jobs only the last field was the SNMPINDEX, not two fields asin yours. But apparently that works too. :-)
Cheers!

[wyang]

All my previous experience with snmp discovery was using the last field as a variable field, as well. It is great that the workaround you recommended works Thanks very much again gert.derouck! I may use this method to try IS-IS discovery.