The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

few SNMP MIB variables (cisco snmp )


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: cisco, snmp,  (найти похожие документы)
From : Martin Ansdell-Smith <[email protected]> Subj : few SNMP MIB variables ------------------------------------------------------------------------------- MIBs we've met This page mentions briefly a few SNMP MIB variables and other indicators that provide useful information about the functioning or malfunctioning of a network. Of course, in reality, all MIB variables are useful in some circumstances but, as with all things, we each have our preferred subsets due to the type of networks we see or the way we approach maintaining or fixing networks. I mention OIDs I have used and found helpful as predictors, informers or diagnostics. In particular I give information on how I have collected information for some of the more obscure stats I have collected with [1]mrtg and cricket. Caveats What I put here I have found to be useful but I might have mis-spelt something vital or just be wrong. Read the [2]disclaimer and check things out for yourself. Even if I got it right it might work on the hardware and software versions I used but not on yours so check things out for yourself. Not all MIB variables on all versions of all software and hardware from all manufacturers contain the correct information. Before you rely on it check it out for yourself. Check it again when you change things, or when some else does. All MIB variable counters (and variables in most programming languages) have a limited range. They will wrap eventually. They might wrap in minutes or even seconds. This matters. Check out for yourself what this means in your network for the variables you are monitoring. Remember that as loadings change, so does the time to wrap. All stats collection consumes resources; storing the information uses more; accessing the information yet more. Statistics collection that seriously impedes live data flows or badly inaccurate statistics may be worse than no statistics at all, though you cannot expect perfection. Check out that you have appropriate resources available to avoid distorting the real traffic flows or presenting faulty data. Finally: be prepared to give a reasonable justification for the statistics you present. Check out for yourself that the information you collect and present is relevant and accurate enough for the purpose. MIB-II Based Variables of Interest MIB-II lives at 1.3.6.1.2.1, see the [3]note below if you are not sure of the significance of this or how to use mrtg or CMU SNMP tools to look at the information. Most of MIB-II is relevant, most is obvious in its use so I'll just mention a few less common variables. Type Code Description .1.3 sysUpTime should increment .2.2.1.11 ifInUcastPkts inbound unicast pkts .2.2.1.12 ifInNUcastPkts inbound nonunicast pkts .4.12 ipOutNoRoutes !=0 => routing problems .6.13 tcpConnTable can process, e.g. for current Oracle sessions .11.4 snmpInBadCommunityNames !=0 may be a security issue .16.1.1.1.13 etherStatsCollisions value irrelevant but big increase might indicate problem. Zero on full-duplex links. .16.1.1.1.12 etherStatsJabbers should be very low .16.1.1.1.6 etherStatsBroadcastPkts .16.1.1.1.7 etherStatsMulticastPkts Proprietary MIBs Hewlett Packard (HP) LaserJet printers (LaserJet 5 (MIO 6) and above but not the ColorLaserJet 5 Enhanced and maybe others) with a JetDirect card (EEPROM A.05.05 and up, I think), can provide useful information including the total number of pages printed, available at 1.3.6.1.2.1.43.10.2.1.4.1.1 (some people have had success with the proprietary MIB 1.3.6.1.4.1.11.2.3.1 but I have not yet). Cisco The majority of these that I use (dozens, perhaps hundreds) are used to gather static information such as names assigned to ports, software versions, cards and modules fitted in chassis (serial number, type, software, firmware) and I have not detailed those here (though I could publish the scripts with OIDs if anyone was interested). Some, however, are useful for real-time data capture. Full details of all supported MIBs and copies of all the MIBs themselves (as v1, v2, SMI and OID lists) are available from ftp.cisco.com. * Router (IOS) CPU Utilization, from the local variables system group in OLD-CISCO-CPU-MIB.my (or OLD-CISCO-SYS-MIB.my): + 1.3.6.1.4.1.9.2.1.56.0 gives avgBusyPer: CPU busy percentage over the last 5s period in the scheduler + 1.3.6.1.4.1.9.2.1.57.0 gives avgBusy1: exponentially-decayed moving average of CPU busy percentage over a 60s period + 1.3.6.1.4.1.9.2.1.58.0 gives avgBusy5: exponentially-decayed moving average of CPU busy percentage over a 300s period I find the last two the most useful to give a feel for utilization. On most routers the two stay together but will deviate when the load is peaky and the router is very busy, I find. These are gauges so do not average the readings over the monitoring period. For example, use the gauge option with [4]mrtg. * Router (IOS) Free Memory 1.3.6.1.4.1.9.2.1.8.0 from OLD-CISCO-MEMORY-MIB is the obvious variable but this is not always, in my limited experience, entirely reliable and is officially obsolete from IOS 11.1. In the ciscoMemoryPoolTable in CISCO-MEMORY-POOL-MIB-V1SMI.my there are instances for used, free and largest contiguous free block of memory for each of the memory pools found on the router. These values are similar to the ones seen with sh mem at the router console. For example, on a 2500 series router there are only two memory pools, proc (pool 1) and i/o (pool 2). The number and names of the pools can be seen by an snmpwalk on 1.3.6.1.4.1.9.9.48.1.1.1.2. In this example, the amount of free memory in each pool can be seen from + 1.3.6.1.4.1.9.9.48.1.1.1.6.1 (enterprises.9.9.48.1.1.1.6.1) gives pool 1 (proc) memory free and + 1.3.6.1.4.1.9.9.48.1.1.1.6.2 gives pool 2 (i/o) memory free. Similarly, + 1.3.6.1.4.1.9.9.48.1.1.1.7.1 gives proc largest contiguous block free + 1.3.6.1.4.1.9.9.48.1.1.1.7.2 gives i/o largest contiguous block free + 1.3.6.1.4.1.9.9.48.1.1.1.5.1 gives proc memory used + 1.3.6.1.4.1.9.9.48.1.1.1.5.2 gives i/o memory used A comparison of sh mem and the OIDs listed here for two sample routers can be seen [5]here. The number of pools depends on the device type. All support processor memory pools and may have other predefined pools and also dynamic pools. Some devices allow pools to be called on by other pools that have run out of memory. The [6]MIB gives the details. When I last looked it pre-defined five memory pools: 1. processor memory 2. i/o memory 3. pci memory 4. fast memory 5. multibus memory * Traffic rate on an interface by Protocol. For example, + IP locIfipInPkts 1.3.6.1.4.1.9.2.2.1.1.42 locIfipOutPkts 1.3.6.1.4.1.9.2.2.1.1.43 locIfipInOctets 1.3.6.1.4.1.9.2.2.1.1.44 locIfipOutOctets 1.3.6.1.4.1.9.2.2.1.1.45 + IPX (Novell) locIfnovellInPkts 1.3.6.1.4.1.9.2.2.1.1.62 locIfnovellOutPkts 1.3.6.1.4.1.9.2.2.1.1.63 locIfnovellInOctets 1.3.6.1.4.1.9.2.2.1.1.64 locIfnovellOutOctets 1.3.6.1.4.1.9.2.2.1.1.65 + Bridged locIfbridgedInPkts 1.3.6.1.4.1.9.2.2.1.1.74 locIfbridgedOutPkts 1.3.6.1.4.1.9.2.2.1.1.75 locIfbridgedInOctets 1.3.6.1.4.1.9.2.2.1.1.76 locIfbridgedOutOctets 1.3.6.1.4.1.9.2.2.1.1.77 + Others (e.g. XNS, CLNS, Appletalk): look in the OLD-CISCO-INTERFACES-MIB for full details * Configuration file moves. I prefer to do this using Expect but it can be done using an SNMP set. Permissions need to be set on the router. The old way used the now deprecated "writeNet" object in the OLD-CISCO-SYSTEM-MIB by setting writeNet.<tftphost> to the octetstring value of <tftpfile>. The recommended MIB is CISCO-CONFIG-COPY-MIB. Full instructions for use are in the MIB. Catalyst 5x0x switches support the CISCO-STACK-MIB which also gives tftp facilities for moving configs and software to and from switch modules. Specifying and Accessing MIB variables SNMP (Simple Network Management) Management Information Base (MIB) variables are referenced by an OID (Object identifier), a sequence of digits and dots. This specifies the position of the variable in the MIB tree. Almost all the MIB variables you see commercially will start with 1.3.6.1 (iso.org.dod.internet) and will then either take the proprietary limb of the tree (.4.1: private.enterprise) the standard limb (2.1: mgmt.mib). There are lots of books that explain this well; My own preference is for Stalling for the explanations and RMON2/SNMPv3 coverage, Feit for the examples from lots of the standard MIBs. After the MIB variable number there has to be an instance defined. This will usually be 0 (zero) where there can only be one (the Cisco Router CPU utilization variable above is an example of this), otherwise it will often be the SNMP index of the interface, for example. Having mentioned the SNMP index of interfaces do be aware that these can change if modules are added or taken away from a chassis, if VLAN configurations change or sub-interfaces are defined, for example. There may also be non-obvious interfaces such as console ports. On some equipment the indexes may not be consecutive. Some software packages try to ease the burden of having to type in lots of numbers and provide mnemonics for some parts of the tree or assume that you are starting at somewhere other than the root of the tree. Read the man and other information that comes with the products. An example would be getting the current value for avgBusy1 from a Cisco router. In mrtg the specified OID would be 1.3.6.1.4.1.9.2.1.57.0, with CMU SNMP-Utilities snmpget the OID would be .1.3.6.1.4.1.9.2.1.57.0 as, without the leading dot it, by default, assumes the OID is in the standard tree (i.e. without the leading dot all the CMU SNMP utilities prefix 1.3.6.2.1. to the specified OID). mrtg now supports the loading of MIBs at run-time, as well as pre-defined OIDs. This greatly simplifies using unusual OIDs (look at the documentation on the loadMIBs global configuration file entry). This page is maintained by Martin Ansdell-Smith (e-mail: [email protected]) using GNU Emacs and RCS on SuSE Linux 6.4. Last modified $Date: 2000/06/13 16:36:41 $.

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру