Performance Management Data for Router Hardware

Performance monitoring in hardware relates mainly to slot positioning in the chassis; the following MIB variables can help you identify the type of interface processors (IPs) installed. Based on the slot positioning of these cards, you can effectively predict and determine the backplane, hardware buffer, and IDB usage in the chassis based on the architectural overview discussed at the beginning of this chapter. Because hardware versions and sometimes serial number ranges (due to Cisco Field Notices) on cards and chassis can affect performance, we also look at ways to gather that information through MIBs and through command-line interface (CLI) commands. The polling period for all these performance management-oriented MIBs should be right after a change management window period because that should be the only time these parameters should change.

MIB Variables for Chassis Information

From OLD-CISCO-CHASSIS-MIB cardTable, MIB variables to watch for chassis information include the following:

• chassisType: Identifies the kind of router the device is.

• chassisVersion: Identifies the hardware version of the router.

• chassisID: Shows the serial number of the chassis itself.

• chassisSlots: Represents how many slots are available in the router for Interface Processors (IPs).

These four MIB objects together produce a nice, concise inventory table on the router model and its corresponding attributes. The purpose of these MIB objects is to give you an understanding of the type of routers that exist in the network. Polling these MIB objects after a change management window is ideal to get an up-to-date and accurate inventory of your network. You can also use this data to quickly assess any issues that may arise, based on Cisco Field Notices, regarding major hardware defects. This data can be used in conjunction with performing the network audit, as explained in Chapter 1, "Conducting the Network Audit."

TIP

You can readily access the Cisco Field Notices via the following URL: http://www.cisco.com/warp/customer/770/.

From ENTITY-MIB (RFC2037), MIB objects related to these four include from the entPhysicalTable:

• entPhysicalVendorType

• entHardwareRevision

• entPhysicalDescr

NOTE

The ENTITY Mib is not supported on the routers until IOS release 11.3(2)NA or greater.

CLI Commands for Chassis Information

Several CLI commands are related to the MIBs just discussed.

show diagbus

The show diagbus command is available only on the high-end routers, such as the 7x00 series. The Slot 31 or "virtual" slot in the 7500 chassis is the output where the equivalent MIB values related to chassis information are reported, except for the chassisSlots. The 7200 series router reports the chassis information in the output from the command show c7200. All other router platforms report the chassis information in the show version output.

Probably the two most useful bits of information you can get from this output, assuming you use SNMP to get the chassisVersion and chassisID, are the board revision and RMA number. These two values cannot be retrieved from SNMP and can only be gathered from CLI commands. The board revision is like the maintenance release of a major IOS version. From the board revision you can determine data points such as "Is my router a 4700 or 4700M?" Output from the show version command is illustrated in Example 10-3, shown later in this chapter.

The RMA number field is used by Cisco's Logistics department to keep a record of the chassis or Interface Processor cards returned to Cisco due to possible customer failure. So, if the value in that field is anything other than 0, the card probably went through the Cisco RMA department. There are no MIB values for the board revision and RMA number.

Example 10-1 shows output from the show diagbus command.

Example 10-1 Obtaining router chassis information with the show diagbus command.

 Router> show diag ... ... Slot 31 (virtual):         EEPROM format version 1 Chassis Interface, HW rev 1.00 A, board revision B0 B Serial number: 03185411 C Part number: 73-1306-02         Test history: 0x00        RMA number: 00-00-00 D         Flags: cisco 7000 board EEPROM contents (hex):           0x20: 01 10 01 00 00 30 9B 03 49 05 1A 02 00 00 00 00           0x30: 58 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00 

Pertinent features of the output in Example 10-1 are flagged with letters A, B, C, etc. (This practice will be followed for subsequent Examples as well.) Here are the meanings of the flagged features:

A "HW rev" is the hardware version of the chassis.

B "board revision" is the appropriate iteration of the hardware version.

C "Serial number" is obviously the serial number of the chassis.

D "RMA number" is used by Cisco to track defective, or possibly defective, routers/cards in the customer base. If the value in this output is equal to 0, the card has not been through Cisco's RMA department, so it has more than likely been in the field since it was first deployed. If the RMA number is not 0, that does not mean the card is bad. It is just a way for Cisco to track the cards that come through the RMA department. Cisco thoroughly tests out the cards prior to redeploying them to the field.

show c7200

The output from show c7200 is the same type of output as the Slot 31 virtual interface from the 7500 series router, except that it's specific for the 7200 series routers.

As with show diagbus, probably the two most useful bits of information you can get from this output are the board revision and RMA number, assuming you use SNMP to get the chassisVersion and chassisID. The board revision can also be obtained from the show version command, as you will see in Example 10-3. In the meantime, Example 10-2 shows sample output from the show c7200 command.

Example 10-2 Obtaining router chassis information with the show c7200 command.

 Router#sh c7200 C7200 Network IO Interrupt Throttling:  throttle count=0, timer count=0  active=0, configured=0  netint usec=3999, netint mask usec=200 C7200 Midplane EEPROM:         Hardware revision 1.3 A  Board revision M0 B         Serial number     8519955 C      Part number    73-1539-03         Test history      0x0           RMA number     00-00-00 D         MAC=0090.bff4.2800, MAC Size=1024         EEPROM format version 1, Model=0x6         EEPROM contents (hex):           0x20: 01 06 01 03 00 82 01 13 49 06 03 03 00 90 BF F4           0x30: 28 00 04 00 00 00 00 00 4C 03 90 B0 FF FF 00 FF C7200 CPU EEPROM:         Hardware revision 2.1 A  Board revision A0 B         Serial number     4390454 C      Part number    73-1536-03         Test history      0x3           RMA number     25-99-30 D         EEPROM format version 1         EEPROM contents (hex):           0x20: 01 15 02 01 00 42 FE 36 49 06 00 03 03 19 63 1E           0x30: 50 00 00 00 FF FF FF FF FF FF FF FF FF FF FF FF 

Here are the meanings of the flagged items in Example 10-2:

A "Hardware revision" is the hardware version of the chassis.

B "Board revision" is the appropriate iteration of the hardware version.

C "Serial number" is obviously the serial number of the chassis.

D "RMA number" is used by Cisco to track defective, or possibly defective, routers/cards in the customer base. If the value in this output is equal to 0, the card has not been through Cisco's RMA department, so it has more than likely been in the field since it was first deployed.

show version

In addition to the IOS version and interface inventory from the show version output, the key data points to look at that relate to the chassis are the processor and chassis revisions as well as the processor ID. Memory, flash, and NVRAM total installed are also reported. Probably the most useful chassis bit of information you can get from this output, assuming you use SNMP to get the chassisVersion and chassisID, is the board revision. There is no MIB variable for board revisions. Example 10-3 shows sample output for show version.

Example 10-3 Obtaining router chassis information with the show version command.

 Router> show version Cisco Internetwork Operating System Software IOS (tm) 4500 Software (C4500-IS56I-M), Experimental Version 11.3(9) Copyright  1986-1999 by cisco Systems, Inc. Compiled Tue 30-Mar-99 14:09 by vilhuber Image text-base: 0x60008930, data-base: 0x608A4000 ROM: System Bootstrap, Version 5.2(7b) [mkamson 7b], RELEASE SOFTWARE (fc1) BOOTFLASH: 4500 Software (C4500-BOOT-M), Version 11.2(8), RELEASE SOFTWARE (fc1) Router uptime is 1 week, 2 days, 20 hours, 32 minutes System restarted by reload at 16:21:04 UTC Thu Apr 8 1999 System image file is "flash:c4500-is56i-mz.jan9", booted via flash cisco 4500 (R4K) processor (revision B A) with 32768K/16384K bytes of memory. Processor board ID 03770977 B R4700 processor, Implementation 33, Revision 1.0 C G.703/E1 software, Version 1.0. Bridging software. X.25 software, Version 3.0.0. 2 Ethernet/IEEE 802.3 interface(s) 2 Token Ring/IEEE 802.5 interface(s) 1 FDDI network interface(s) 128K D bytes of non-volatile configuration memory. 16384K E bytes of processor board System flash (Read/Write) 4096K F bytes of processor board Boot flash (Read/Write) Configuration register is 0x2102 G 

Here are the meanings of the flagged items in Example 10-2:

A The first "revision" seen in the show version output is equivalent to the "board revision" from the show diag output. From here, you can determine whether or not your router is a 4500 or 4500-M. In this case, this router is a 4500-M based on the revision of "B." You can search Cisco Connection Online for details on the different revisions, especially under the OpenForum section: http://www.cisco.com/cgi-bin/search-openf.

B The "Processor board ID" is equivalent to the chassisID MIB.

C The second "revision" seen in this output is the hardware version of the chassis or chassisVersion.

D The "non-volatile configuration memory" line shows you how much NVRAM is installed in the router. Configurations are stored in the NVRAM.

E The "processor board system flash" line shows how much system flash memory is installed on the router. IOS images are mainly stored in flash. Sometimes, the configuration files can reside here as well. There may also be PCMCIA flash memory as well to help store IOS images or configurations.

F The "bootflash" line is the amount of bootflash installed in the router. Bootflash is used to store the initial IOS image and is like the "reserve" IOS image, in case the main flash IOS image is not present or working correctly. It is like the ROM on older platform routers.

G The "configuration register" line shows the bit settings of the router that gives the router its boot characteristics, such as boot from flash or from bootflash, or try to boot so many times from flash and then boot from bootflash.

TIP

It is recommended to keep the configuration register setting at 0x2102. This setting tells the router to boot from system flash and if it fails five times and then boot from bootflash or ROM, and to ignore the BREAK key, which halts the boot process.

MIB Variables for Card Information

From OLD-CISCO-CHASSIS MIB cardTable, MIB variables to watch for card information include the following:

• CardType: The kind of card installed in the router, especically modularized routers.

• CardDescr: A text description of the card.

• CardSerial: The serial number of the card.

• CardHwVersion: The hardware revision of the card.

• CardSwVersion: The firmware or microcode version of the card.

• CardSlotNumber: The slot relative to the location of the card in the chassis. If slot position is irrelevant, a 1 value will be present on low-end routers (4x00 series, etc.), for example.

• CardOperStatus: The operational status of the card. The values are "up" when a card is recognized by the device and is enabled for operation; they are "down" if the card is not recognized by the device, or if it is not enabled for operation; they are "standby" if the card is enabled and acting as a standby slave.

The purpose of these MIB objects is to give you an understanding of the type of cards installed in the network. Polling these MIB objects after a change management window is ideal to get an up-to-date and accurate inventory of your network. You can also use this data to quickly assess any issues that may arise with particular common hardware platforms based on Cisco Field Notices that may come out regarding major hardware defects. From ENTITY-MIB (RFC2037), MIB objects related to these four include the following from the entPhysicalTable:

• EntPhysicalVendorType

• entHardwareRevision

• entPhysicalDescr

• entSerialNumber

• entPhysicalParentRelPos

CLI Commands for Card Information

Several CLI commands are related to the MIBs just discussed.

show controller cbus

This command displays the hardware characteristics of each card in the 7x00 series router. Things such as hardware revisions, microcode levels, card types, and hardware buffer memory allocation are displayed in this output. The main bit of data that can be gathered from this command that cannot be gathered via SNMP is the hardware buffer pool allocation from MEMD. This is where the concept of over-subscription really hits home. If there are no hardware buffers available in the router, or if there are a low amount of hardware buffers, interfaces will fail to perform as designed and "ignores" will increment on the interfaces when congestion occurs. Slot position, card type, hardware version, and microcode version are also available in this output as well.

Example 10-4 Obtaining router card information with show controller cbus.

 Router#show controller cbus MEMD at 40000000, 2097152 bytes (unused 3584, recarves 1, lost 0)   RawQ 48000100, ReturnQ 48000108, EventQ 48000110   BufhdrQ 48000128 (2809 items), LovltrQ 48000140 (10 items, 2016 bytes)   IpcbufQ 48000150 (16 items, 4096 bytes)   IpcbufQ_classic 48000148 (8 items, 4096 bytes)   3570 buffer headers (48002000 - 4800FF10)   pool0: 9 buffers, 256 bytes A, queue 48000130   pool1: 481 buffers, 1536 bytes A, queue 48000138   pool2: 233 buffers, 4544 bytes A, queue 48000158   pool3: 4 buffers, 4576 bytes, A queue 48000160   slot1 B: AIP C, hw 1.3D, sw 20.18 E, ccb 5800FF30, cmdq 48000088, vps 8192     software loaded from system     ATM1/0, applique is SONET (155Mbps)       gfreeq 48000158, lfreeq 48000168 (4544 bytes)       rxlo 4 F, rxhi 189 G, rxcurr 0, maxrxcurr 0       txq 48000170, txacc 48000082 (value 0), txlimit 66 H   slot4 B: VIP2 C, hw 2.4 D, sw 22.20 E, ccb 5800FF60, cmdq 480000A0, vps 8192     software loaded from system     IOS (tm) VIP Software (SVIP-DW-M), Version 12.0(2)T,  RELEASE SOFTWARE (fc1)     ROM Monitor version 17.0     FastEthernet4/0/0, addr 0090.f2d0.e080 (bia 0090.f2d0.e080)       gfreeq 48000138, lfreeq 48000178 (1536 bytes)       rxlo 4 F, rxhi 481 G, rxcurr 2, maxrxcurr 3       txq 48001A00, txacc 48001A02 (value 320), txlimit 320 H     FastEthernet4/0/1, addr 0090.f2d0.e081 (bia 0090.f2d0.e081)       gfreeq 48000138, lfreeq 48000180 (1536 bytes)       rxlo 4, rxhi 481, rxcurr 0, maxrxcurr 0       txq 48001A08, txacc 48001A0A (value 0), txlimit 320 

Here are the meanings of the flagged items in Example 10-4:

A Buffer pool assignment based on the MEMD buffer carving algorithm aforementioned in the introduction of this chapter.

B Slot position of the Interface Processor (IP). Equivalent to MIB cardSlotNumber.

C Interface Processor (IP) Type: Equivalent to MIB cardType.

D "hw" is the hardware version of the IP, which is equivalent to MIB cardHwVersion.

E "sw" is the microcode version of the IP, which is typically "bundled" within the IOS and downloaded at boot time. Microcode levels hold true only for the 7x00 series routers. The "bundled" microcode can be overridden by a separate microcode version stored in Flash memory. This is equivalent to the MIB cardSwVersion.

F "rxlo" is the minimum amount of receive hardware buffers allowed on the particular interface. This is based again on the MEMD buffer carving algorithm performed at boot time.

G "rxhi" is the maximum amount of receive hardware buffers allowed on the particular interface. This is based again on the MEMD buffer carving algorithm performed at boot time.

H "txlimit" is the transmit buffer limit for the particular interface. This is the only value that can be changed via the command line (CLI) prompt, via the configuration command tx-queue-limit. This command should not be used unless instructed to do so by a Cisco Support Engineer (TAC).

show diagbus

This command shows you the hardware information for the high-end routers. The board revision and insertion time are the two fields displayed in this output that cannot be retrieved from a MIB object. Probably the three most useful bits of information you can get from this output, assuming you use SNMP to get the chassisVersion and chassisID, are the board revision, RMA number, and insertion time.

The insertion time is the time at which the Interface Processor card was inserted into the router. If this value is different from the router uptime, you know that the card was probably OIRed (Online Insertion and Removal). You can correlate this time with the OIR syslog messages seen, such as %OIR-6-INSCARD.

Example 10-5 shows sample output from show diagbus, with emphasis on card information.

Example 10-5 Obtaining router card information with show diagbus.

 Router#sh diagbus Slot 1:         Physical slot 1 A, ~physical slot 0xE, logical slot 1, CBus 0         Microcode Status 0x0         Master Enable, LED, WCS Loaded         Board is analyzed         EEPROM format version 1         EIPB controller, HW rev 1.07 C, board revision D0 D         Serial number: 03356234 E Part number: 73-0906-04         Test history: 0x0E        RMA number: 05-20-19 F         Flags: cisco 7000 board; 7500 compatible         EEPROM contents (hex):           0x20: 01 00 01 07 00 33 36 4A 49 03 8A 04 0E 05 14 13           0x30: 68 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00         Slot database information:         Flags: 0x4      Insertion time: 0x1A38 (4w0d ago) G Slot 2:         EEPROM format version 1         Route/Switch Processor 2 B, HW rev 1.02 C, board revision B0 D         Serial number: 03719351 E Part number: 73-1324-05         Test history: 0x0E        RMA number: 00-00-00 F         Flags: cisco 7000 board; 7500 compatible         EEPROM contents (hex):           0x20: 01 0F 01 02 00 38 C0 B7 49 05 2C 05 0E 00 00 00           0x30: 58 FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 Slot 6:         Physical slot 6 A, ~physical slot 0x9, logical slot 6 , CBus 0         Microcode Status 0x4         Master Enable, LED, WCS Loaded         Board is analyzed         Pending I/O Status: None         EEPROM format version 1         VIP2 B controller, HW rev 2.10 C, board revision B0 D         Serial number: 08206403 E Part number: 73-1684-04         Test history: 0x00        RMA number: 00-00-00 F         Flags: cisco 7000 board; 7500 compatible EEPROM contents (hex):           0x20: 01 15 02 0A 00 7D 38 43 49 06 94 04 00 00 00 00           0x30: 58 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00    Slot database information:         Flags: 0x4      Insertion time: 0x1A38 (4w0d ago) [G}        Controller Memory Size: 64 MBytes DRAM, 2048 KBytes SRAM PA Bay 0 A Information:                 Token Ring PA, 4 portsPA-4R B                 EEPROM format version 1                 HW rev 1.10 C, Board revision A0 D                 Serial number: 04948569 E Part number: 73-1390-05 --Boot log begin-- Cisco Internetwork Operating System Software IOS (tm) VIP Software (SVIP-DW-M), Version 11.2(17)P,  RELEASE SOFTWARE (fc1) Copyright  1986-1999 by cisco Systems, Inc. Compiled Tue 12-Jan-99 12:22 by pwade Image text-base: 0x600108D0, data-base: 0x6015C000 --Boot log end-- Slot 31 (virtual):         EEPROM format version 1         Chassis Interface B, HW rev 1.00 C, board revision B0 D         Serial number: 03185411 E Part number: 73-1306-02         Test history: 0x00        RMA number: 00-00-00 F         Flags: cisco 7000 board         EEPROM contents (hex):           0x20: 01 10 01 00 00 30 9B 03 49 05 1A 02 00 00 00 00           0x30: 58 00 00 00 FF 00 00 00 00 00 00 00 00 00 00 00 

Here are the meanings of the flagged items in Example 10-5:

A "Physical slot" is the slot position of the IP card. Equivalent to MIB cardSlotNumber.

B The preceding acronym or word to "controller" is the IP type or MIB cardType.

C B"HW rev" is the hardware version of the chassis.

D "board revision" is the appropriate iteration of the hardware version.

E "Serial number" is obviously the serial number of the chassis.

F "RMA number" is used by Cisco to track defective, or possibly defective, routers/cards in the customer base. If the value in this output is equal to 0, then the card has not been through Cisco's RMA department, thus has more than likely been in the field since it was first deployed.

"Insertion time" is the time when the Interface Processor (IP) card was inserted in the chassis.

show controller

This command is useful on the low-end routers such as the 4x00, 3600, 2500, and 2600 series platforms. It produces the same kind of output as show controller cbus for the high-end routers, but in a little different format. If you execute this command as is on the high-end routers, it will produce output specifically for the token ring interfaces if they exist; otherwise, no output will be displayed.

From this output, you can retrieve the NIM (Network Interface Module) chip set based on the cardType, slot position of the NIM, and the hardware version of the NIM. The chipset is probably the most useful out of this output. The output from this command varies due to the different kinds of chip sets and reported output for each kind of card and router type. See Example 10-6 for an illustration of the different reporting styles (for example, LANE versus FDDI).

To get the hardware information on low-end routers, it may be more effective to use SNMP to get the cardType and cardHwVersion than to use the CLI command show controller to get the same set of data points.

Example 10-6 Obtaining router card information with show controller.

 Router#sh controller LANCE A unit 0, NIM slot 0 B, NIM type code 9, NIM version 2 C Media Type is 10BaseT, Link State is Up, Squelch is Normal idb 0x60CB060C, ds 0x60CB1E88, eim_regs = 0x3C000000 IB at 0x40006F18: mode=0x0000, mcfilter 0000/0002/0100/0080 station address 0060.837b.5850  default station address 0060.837b.5850 buffer size 1524 RX ring with 32 entries at 0x40006F60 Rxhead = 0x40006F60 (0), Rxp = 0x60CB1EA0 (0) 00 pak=0x60CBA3E4 ds=0xA8021D62 status=0x80 max_size=1524 pak_size=0 ... ... LANCE A unit 1, NIM slot 0 B, NIM type code 9, NIM version 2 C Media Type is 10BaseT, Link State is Down, Squelch is Normal idb 0x60CBE81C, ds 0x60CC0098, eim_regs = 0x3C000800 IB at 0x4002FBD4: mode=0x0000, mcfilter 0000/0000/0100/0000 station address 0060.837b.5853  default station address 0060.837b.5853 buffer size 1524 RX ring with 32 entries at 0x4002FC18 Rxhead = 0x4002FC18 (0), Rxp = 0x60CC00B0 (0) 00 pak=0x60CC85F4 ds=0xA804AA1E status=0x80 max_size=1524 pak_size=0 ... ... FDDI A: unit 0, NIM slot 1 B, NIM type code 3, NIM version 3 C  dual attach, state 4, idb 0x60CCCA2C, ds 0x60CCE290, module_regs 0x3C100000  Phy-A is multi mode, Phy-B is multi mode  hardware address: 0060.837b.5851 (wire order 0006.c1de.1a8a)  default hardware address: 0060.837b.5851  loopback disabled  CAM hardware present (Software: Rev 17, Tue Oct 17 08:34:02 PDT 1995)  Registers: csr = 0x7003  BSI silicon revision Number 0x0000004C (BSI-2 Rev B)  Registers: mr 0x10, pcar 0x4A, mbar 0x5, mar 0x0 ... ... 

A On the low-end routers, you'll see the cardType defined here as representative of the chipset typically for the appropriate media type.

B "NIM slot" is the position of the Network Interface Module in the router. The positioning is especially important on the modularized routers such as the 4x00, 3600, and 2600 series routers.

C "NIM version" is the hardware version of the NIM. This is equivalent to the cardHwVersion MIB.

Syslog Messages for Card Information

A number of syslog messages are useful for router chassis performance management, and apply directly to the MIB objects and CLI commands previously discussed. They are collected in Table 10-2.

Table 10-2. Syslog Messages for Card Information

Message	Explanation
%OIR-6-INSCARD:Card inserted in slot [dec], subcard [dec], interfaces administratively shutdown	The specified hot-swappable card was inserted in the system. The interface(s) on the card will remain administratively disabled until specifically enabled because they may need to be configured. This is an informational message only. Configure the interface(s) and enable them.
%OIR-6-REMCARD:Card removed from slot [dec], subcard[dec], interfaces disabled	The specified hot-swappable card was removed from the system. This is an informational message only. No action is required.
%OIR-4 NOEOIR:[char] [char] version [int].[int] not capable of EOIR	This card is capable of online insertion and removal (OIR), but is not capable of extended online insertion and removal (EOIR). Even though no damage would occur to the hardware, removal or reinsertion of the card will cause a CBUS complex restart, which would be disruptive to traffic on other cards in the system. Try to restrict removal or reinsertion of this card to instances when a CBUS complex restart will be least disruptive. Or, upgrade the card to the latest revision that supports EOIR.

Chassis and Card Information via the Entity MIB

There are several MIBs to watch for chassis and card information. Those from the ENTITY-MIB (RFC2037) from the entPhysicalTable with the CISCO-ENTITY-VENDORTYPE-OID-MIB and CISCO-ENTITY-ASSET-MIB are as follows:

• entPhysicalVendorType: Equivalent to chassisType and cardType

• entHardwareRevision: Equivalent to chassisVersion

• entPhysicalDescr: Equivalent to cardDescr

• entSerialNumber: Equivalent to cardSerial,

• entPhysicalParentRelPos: Equivalent to cardSwVersion, cardHwVersion, and cardSlotNumber

The MIB describes managed objects used for managing multiple logical and physical entities managed by a single SNMP agent. The hardware is generalized into one of the following types: chassis, backplane, container, powerSupply, fan, sensor, module, or port. This MIB is flexible enough to determine the hardware type based on an MIB definition relating to the ENTITY MIB. In this case, that MIB is called CISCO-ENTITY-VENDORTYPE OID MIB. The purpose of these MIBs is to replace the existing OLD-CISCO-CHASSIS-MIB and make it more of a standard based on the RFC 2037 definition. The only MIB not covered by the ENITITY MIB is the chassisID MIB.