Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
Community Member

FWSM multi-context has different oids for each context for the same SNMP-statistics

Hello.

I have two FWSM with firmware version 4.1(14) installed in two Cat6509 VSS switches.

Overall I have 26 contexts divided into two failover groups, so I have active\active failover scenario.

With awesome pdf-manual http://jklogic.net/content/files/FWSM%20OID%20Info.pdf I have found a few OIDs I interested to gathering statistics.

For example lets take OID 1.3.6.1.4.1.9.9.480.1.1.4.1.6 - crlRateLimitCurrentUsage - Current resource usage. So here we can gathering statistics with current connection counts.

I make a small shell-script to checking how this OID is ok for my monitoring systems:

snmpwalk -v 2c -c public 192.168.43.3 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.43.4 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.43.5 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.43.6 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.43.7 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.43.10 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.43.11 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.43.12 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.43.13 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.43.14 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.43.15 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.44.3 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.44.4 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.44.5 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.44.6 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.44.7 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.44.8 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.44.9 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.44.10 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.44.11 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.44.13 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.44.14 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.44.15 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

snmpwalk -v 2c -c public 192.168.44.16 1.3.6.1.4.1.9.9.480.1.1.4.1.6 | head -1

192.168.43.3-15 are contexts from failover group 1 and 192.168.44.3-16 are contexts from failover group 2.

Here is output:

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.98.114.111.110.122.101.5 = Gauge32: 0

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.115.105.108.118.101.114.5 = Gauge32: 5

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.115.105.108.118.101.114.5 = Gauge32: 33

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.115.105.108.118.101.114.5 = Gauge32: 1

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.98.114.111.110.122.101.5 = Gauge32: 0

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.4.103.111.108.100.5 = Gauge32: 56

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.98.114.111.110.122.101.5 = Gauge32: 2

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.115.105.108.118.101.114.5 = Gauge32: 2

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.98.114.111.110.122.101.5 = Gauge32: 13

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.115.105.108.118.101.114.5 = Gauge32: 14

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.115.105.108.118.101.114.5 = Gauge32: 0

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.98.114.111.110.122.101.5 = Gauge32: 1

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.98.114.111.110.122.101.5 = Gauge32: 0

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.115.105.108.118.101.114.5 = Gauge32: 0

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.115.105.108.118.101.114.5 = Gauge32: 15

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.98.114.111.110.122.101.5 = Gauge32: 0

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.98.114.111.110.122.101.5 = Gauge32: 0

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.98.114.111.110.122.101.5 = Gauge32: 14

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.98.114.111.110.122.101.5 = Gauge32: 0

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.98.114.111.110.122.101.5 = Gauge32: 4

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.115.105.108.118.101.114.5 = Gauge32: 4

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.98.114.111.110.122.101.5 = Gauge32: 0

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.115.105.108.118.101.114.5 = Gauge32: 45

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.115.105.108.118.101.114.5 = Gauge32: 0

So you can see that the same statistics of current connection count used different suffix in OID:

first part the same:

iso.3.6.1.4.1.9.9.480.1.1.4.1.6.6.

second part is different:

115.105.108.118.101.114.          or

98.114.111.110.122.101.            or

103.111.108.100.

third part is the same:

.5 - this is applied to connection statistics.

As you can see we have different middle-part which I can`t explain how to decode. So I can set-up my network monitoring systems to gather the same information from different contexts.

Do you know how this part appear? What to do to force this OID be the same?

Everyone's tags (3)
232
Views
0
Helpful
0
Replies
CreatePlease to create content