Tuesday, February 9, 2016

How to determine the number of slots in a Catalyst 6500 or 7600

For capacity management kpis, could be interesting to know via snmp how many slots are in use in a 6500.
This can be achieved by using snmp mib:
server# snmpwalk -v 2c -c public 10.1.1.1 .1.3.6.1.2.1.47.1.1.1.1.7
SNMPv2-SMI::mib-2.47.1.1.1.1.7.1 = STRING: "WS-C6509-E"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.2 = STRING: "Physical Slot 1"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.3 = STRING: "Physical Slot 2"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.4 = STRING: "Physical Slot 3"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.5 = STRING: "Physical Slot 4"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.6 = STRING: "Physical Slot 5"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.7 = STRING: "Physical Slot 6"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.8 = STRING: "Physical Slot 7"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.9 = STRING: "Physical Slot 8"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.10 = STRING: "Physical Slot 9"
SNMPv2-SMI::mib-2.47.1.1.1.1.7.11 = STRING: "Backplane"

Thursday, February 4, 2016

Problem with bgp status snmp queries

I have been seen a problem in Cisco Catalyst line, either 3560 or 6500, with snmp queries returning snmp status.
For example,
1.3.6.1.2.1.15.3.1.1 ->  returns peer ip
1.3.6.1.2.1.15.3.1.2 ->  returns peer status
  1 : idle
  2 : connect
  3 : active
  4 : opensent
  5 : openconfirm
  6 : established

When ever there is a  returned mib with value:
SNMPv2-SMI::mib-2.15.3.1.1.10.1.1.1= IpAddress: 0.0.0.0

Then, the snmp status will be
SNMPv2-SMI::mib-2.15.3.1.2.10.1.1.1= INTEGER: 1



when the returned value should be:
SNMPv2-SMI::mib-2.15.3.1.2.10.1.1.1= INTEGER: 6 ---> established.








So far, I have no workaround.