idnits 2.17.1 draft-ietf-entmib-v3-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2552 has weird spacing: '...imed to perta...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (27 August 2003) is 7547 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2574' is mentioned on line 2707, but not defined ** Obsolete undefined reference: RFC 2574 (Obsoleted by RFC 3414) == Missing Reference: 'RFC2575' is mentioned on line 2708, but not defined ** Obsolete undefined reference: RFC 2575 (Obsoleted by RFC 3415) -- Obsolete informational reference (is this intentional?): RFC 1493 (Obsoleted by RFC 4188) -- Obsolete informational reference (is this intentional?): RFC 1516 (Obsoleted by RFC 2108) -- Obsolete informational reference (is this intentional?): RFC 2037 (Obsoleted by RFC 2737) -- Obsolete informational reference (is this intentional?): RFC 2737 (Obsoleted by RFC 4133) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Entity MIB Working Group Andy Bierman 3 Internet Draft Keith McCloghrie 4 Cisco Systems, Inc. 5 27 August 2003 7 Entity MIB (Version 3) 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026 [RFC2026]. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference material 23 or to cite them other than as "work in progress". 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this document is unlimited. Please send comments to the 32 Entity MIB Working Group, . 34 1. Copyright Notice 36 Copyright (C) The Internet Society (2003). All Rights Reserved. 38 "Abstract" 39 This memo defines a portion of the Management Information Base (MIB) for 40 use with network management protocols in the Internet community. In 41 particular, it describes managed objects used for managing multiple 42 logical and physical entities managed by a single SNMP agent. This 43 document specifies version 3 of the Entity MIB, which obsoletes version 44 2 (RFC 2737). 46 2. Table of Contents 48 1 Copyright Notice ................................................ 1 49 2 Table of Contents ............................................... 2 50 3 The SNMP Management Framework ................................... 3 51 4 Overview ........................................................ 3 52 4.1 Terms ......................................................... 4 53 4.2 Relationship to Community Strings ............................. 5 54 4.3 Relationship to SNMP Contexts ................................. 6 55 4.4 Relationship to Proxy Mechanisms .............................. 6 56 4.5 Relationship to a Chassis MIB ................................. 6 57 4.6 Relationship to the Interfaces MIB ............................ 7 58 4.7 Relationship to the Other MIBs ................................ 7 59 4.8 Relationship to Naming Scopes ................................. 7 60 4.9 Multiple Instances of the Entity MIB .......................... 8 61 4.10 Re-Configuration of Entities ................................. 8 62 4.11 Textual Convention Change .................................... 9 63 4.12 MIB Structure ................................................ 9 64 4.12.1 entityPhysical Group ....................................... 9 65 4.12.2 entityLogical Group ........................................ 10 66 4.12.3 entityMapping Group ........................................ 11 67 4.12.4 entityGeneral Group ........................................ 11 68 4.12.5 entityNotifications Group .................................. 12 69 4.13 Multiple Agents .............................................. 12 70 4.14 Changes Since RFC 2037 ....................................... 12 71 4.14.1 Textual Conventions ........................................ 12 72 4.14.2 New entPhysicalTable Objects ............................... 12 73 4.14.3 New entLogicalTable Objects ................................ 13 74 4.14.4 Bugfixes ................................................... 13 75 4.15 Changes Since RFC 2737 ....................................... 13 76 4.15.1 Textual Conventions ........................................ 13 77 4.15.2 Deprecated Objects ......................................... 13 78 4.15.3 Bugfixes ................................................... 13 79 5 Definitions ..................................................... 14 80 6 Usage Examples .................................................. 45 81 6.1 Router/Bridge ................................................. 45 82 6.2 Repeaters ..................................................... 51 83 7 Intellectual Property ........................................... 59 84 8 Acknowledgements ................................................ 59 85 9 Normative References ............................................ 59 86 10 Informative References ......................................... 60 87 11 Security Considerations ........................................ 62 88 12 Authors' Addresses ............................................. 64 89 13 Full Copyright Statement ....................................... 65 90 *** TOC line *** 91 *** TOC line *** 92 *** TOC line *** 93 *** TOC line *** 94 *** TOC line *** 95 *** TOC line *** 97 3. The SNMP Management Framework 99 For a detailed overview of the documents that describe the current 100 Internet-Standard Management Framework, please refer to section 7 of RFC 101 3410 [RFC3410]. 103 Managed objects are accessed via a virtual information store, termed the 104 Management Information Base or MIB. MIB objects are generally accessed 105 through the Simple Network Management Protocol (SNMP). Objects in the 106 MIB are defined using the mechanisms defined in the Structure of 107 Management Information (SMI). This memo specifies a MIB module that is 108 compliant to the SMIv2, which is described in STD 58, RFC 2578 109 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 111 4. Overview 113 There is a need for a standardized way of representing a single agent 114 which supports multiple instances of one MIB. This is presently true 115 for at least 3 standard MIBs, and is likely to become true for more and 116 more MIBs as time passes. For example: 118 - multiple instances of a bridge supported within a single device 119 having a single agent; 121 - multiple repeaters supported by a single agent; 123 - multiple OSPF backbone areas, each one operating as part of its own 124 Autonomous System, and each identified by the same area-id (e.g., 125 0.0.0.0), supported inside a single router with one agent. 127 The fact that it is a single agent in each of these cases implies there 128 is some relationship which binds all of these entities together. 129 Effectively, there is some "overall" physical entity which houses the 130 sum of the things managed by that one agent, i.e., there are multiple 131 "logical" entities within a single physical entity. Sometimes, the 132 overall physical entity contains multiple (smaller) physical entities 133 and each logical entity is associated with a particular physical entity. 134 Sometimes, the overall physical entity is a "compound" of multiple 135 physical entities (e.g., a stack of stackable hubs). 137 What is needed is a way to determine exactly what logical entities are 138 managed by the agent (with some version of SNMP), and thereby to be able 139 to communicate with the agent about a particular logical entity. When 140 different logical entities are associated with different physical 141 entities within the overall physical entity, it is also useful to be 142 able to use this information to distinguish between logical entities. 144 In these situations, there is no need for varbinds for multiple logical 145 entities to be referenced in the same SNMP message (although that might 146 be useful in the future). Rather, it is sufficient, and in some 147 situations preferable, to have the context/community in the message 148 identify the logical entity to which the varbinds apply. 150 Version 2 of this MIB addresses new requirements that have emerged since 151 the publication of the first Entity MIB (RFC 2037 [RFC2037]). There is 152 a need for a standardized way of providing non-volatile, 153 administratively assigned identifiers for physical components 154 represented with the Entity MIB. There is also a need to align the 155 Entity MIB with the SNMPv3 administrative framework (STD 62, RFC 3411 156 [RFC3411]). Implementation experience has shown that additional 157 physical component attributes are also desirable. 159 Version 3 of this MIB addresses new requirements that have emerged since 160 the publication of the second Entity MIB (RFC 2737 [RFC2737]). There is 161 a need for identifying physical entities which are central processing 162 units (CPUs) and a need to provide a textual convention which identifies 163 an entPhysicalIndex value or zero, where the value zero has application- 164 specific semantics. 166 4.1. Terms 168 Some new terms are used throughout this document: 170 - Naming Scope 171 A "naming scope" represents the set of information that may be 172 potentially accessed through a single SNMP operation. All instances 173 within the naming scope share the same unique identifier space. 174 For SNMPv1, a naming scope is identified by the value of the 175 associated 'entLogicalCommunity' instance. For SNMPv3, the term 176 'context' is used instead of 'naming scope'. The complete 177 definition of an SNMP context can be found in section 3.3.1 of RFC 178 3411 [RFC3411]. 180 - Multi-Scoped Object 181 A MIB object, for which identical instance values identify 182 different managed information in different naming scopes, is called 183 a "multi-scoped" MIB object. 185 - Single-Scoped Object 186 A MIB object, for which identical instance values identify the same 187 managed information in different naming scopes, is called a 188 "single-scoped" MIB object. 190 - Logical Entity 191 A managed system contains one or more logical entities, each 192 represented by at most one instantiation of each of a particular 193 set of MIB objects. A set of management functions is associated 194 with each logical entity. Examples of logical entities include 195 routers, bridges, print-servers, etc. 197 - Physical Entity 198 A "physical entity" or "physical component" represents an 199 identifiable physical resource within a managed system. Zero or 200 more logical entities may utilize a physical resource at any given 201 time. It is an implementation-specific manner as to which physical 202 components are represented by an agent in the EntPhysicalTable. 203 Typically, physical resources (e.g., communications ports, 204 backplanes, sensors, daughter-cards, power supplies, the overall 205 chassis) which can be managed via functions associated with one or 206 more logical entities are included in the MIB. 208 - Containment Tree 209 Each physical component may be modeled as 'contained' within 210 another physical component. A "containment-tree" is the conceptual 211 sequence of entPhysicalIndex values which uniquely specifies the 212 exact physical location of a physical component within the managed 213 system. It is generated by 'following and recording' each 214 'entPhysicalContainedIn' instance 'up the tree towards the root', 215 until a value of zero indicating no further containment is found. 217 4.2. Relationship to Community Strings 219 For community-based SNMP, distinguishing between different logical 220 entities is one (but not the only) purpose of the community string (RFC 221 1157 [RFC1157]). This is accommodated by representing each community 222 string as a logical entity. 224 Note that different logical entities may share the same naming scope 225 (and therefore the same values of entLogicalCommunity). This is 226 possible, providing they have no need for the same instance of a MIB 227 object to represent different managed information. 229 4.3. Relationship to SNMP Contexts 231 Version 2 of the Entity MIB contains support for associating SNMPv3 232 contexts with logical entities. Two new MIB objects, defining an 233 SnmpEngineID and ContextName pair, are used together to identify an SNMP 234 context associated with a logical entity. This context can be used (in 235 conjunction with the entLogicalTAddress and entLogicalTDomain MIB 236 objects) to send SNMPv3 messages on behalf of a particular logical 237 entity. 239 4.4. Relationship to Proxy Mechanisms 241 The Entity MIB is designed to allow functional component discovery. The 242 administrative relationships between different logical entities are not 243 visible in any Entity MIB tables. An NMS cannot determine whether MIB 244 instances in different naming scopes are realized locally or remotely 245 (e.g., via some proxy mechanism) by examining any particular Entity MIB 246 objects. 248 The management of administrative framework functions is not an explicit 249 goal of the Entity MIB WG at this time. This new area of functionality 250 may be revisited after some operational experience with the Entity MIB 251 is gained. 253 Note that for community-based versions of SNMP, a network administrator 254 will likely be able to associate community strings with naming scopes 255 with proprietary mechanisms, as a matter of configuration. There are no 256 mechanisms for managing naming scopes defined in this MIB. 258 4.5. Relationship to a Chassis MIB 260 Some readers may recall that a previous IETF working group attempted to 261 define a Chassis MIB. No consensus was reached by that working group, 262 possibly because its scope was too broad. As such, it is not the 263 purpose of this MIB to be a "Chassis MIB replacement", nor is it within 264 the scope of this MIB to contain all the information which might be 265 necessary to manage a "chassis". On the other hand, the entities 266 represented by an implementation of this MIB might well be contained in 267 a chassis. 269 4.6. Relationship to the Interfaces MIB 271 The Entity MIB contains a mapping table identifying physical components 272 that have 'external values' (e.g., ifIndex) associated with them within 273 a given naming scope. This table can be used to identify the physical 274 location of each interface in the ifTable (RFC 2863 [RFC2863]). Since 275 ifIndex values in different contexts are not related to one another, the 276 interface to physical component associations are relative to the same 277 logical entity within the agent. 279 The Entity MIB also contains 'entPhysicalName' and 'entPhysicalAlias' 280 objects, which approximate the semantics of the 'ifName' and 'ifAlias' 281 objects (respectively) from the Interfaces MIB [RFC2863], for all types 282 of physical components. 284 4.7. Relationship to the Other MIBs 286 The Entity MIB contains a mapping table identifying physical components 287 that have identifiers from other standard MIBs associated with them. 288 For example, this table can be used along with the physical mapping 289 table to identify the physical location of each repeater port in the 290 rptrPortTable, or each interface in the ifTable. 292 4.8. Relationship to Naming Scopes 294 There is some question as to which MIB objects may be returned within a 295 given naming scope. MIB objects which are not multi-scoped within a 296 managed system are likely to ignore context information in 297 implementation. In such a case, it is likely such objects will be 298 returned in all naming scopes (e.g., not just the 'default' naming scope 299 or the SNMPv3 default context). 301 For example, a community string used to access the management 302 information for logical device 'bridge2' may allow access to all the 303 non-bridge related objects in the 'default' naming scope, as well as a 304 second instance of the Bridge MIB (RFC 1493 [RFC1493]). 306 It is an implementation-specific matter as to the isolation of single- 307 scoped MIB objects by the agent. An agent may wish to limit the objects 308 returned in a particular naming scope to just the multi-scoped objects 309 in that naming scope (e.g., system group and the Bridge MIB). In this 310 case, all single-scoped management information would belong to a common 311 naming scope (e.g., 'default'), which itself may contain some multi- 312 scoped objects (e.g., system group). 314 4.9. Multiple Instances of the Entity MIB 316 It is possible that more than one agent exists in a managed system, and 317 in such cases, multiple instances of the Entity MIB (representing the 318 same managed objects) may be available to an NMS. 320 In order to reduce complexity for agent implementation, multiple 321 instances of the Entity MIB are not required to be equivalent or even 322 consistent. An NMS may be able to 'align' instances returned by 323 different agents by examining the columns of each table, but vendor- 324 specific identifiers and (especially) index values are likely to be 325 different. Each agent may be managing different subsets of the entire 326 chassis as well. 328 When all of a physically-modular device is represented by a single 329 agent, the entry for which entPhysicalContainedIn has the value zero 330 would likely have 'chassis' as the value of its entPhysicalClass; 331 alternatively, for an agent on a module where the agent represents only 332 the physical entities on that module (not those on other modules), the 333 entry for which entPhysicalContainedIn has the value zero would likely 334 have 'module' as the value of its entPhysicalClass. 336 An agent implementation of the entLogicalTable is not required to 337 contain information about logical entities managed primarily by other 338 agents. That is, the entLogicalTAddress and entLogicalTDomain objects in 339 the entLogicalTable are provided to support an historical multiplexing 340 mechanism, not to identify other SNMP agents. 342 Note that the Entity MIB is a single-scoped MIB, in the event an agent 343 represents the MIB in different naming scopes. 345 4.10. Re-Configuration of Entities 347 Most of the MIB objects defined in this MIB have at most a read-only 348 MAX-ACCESS clause. This is a conscious decision by the working group to 349 limit this MIB's scope. The second version of the Entity MIB allows a 350 network administrator to configure some common attributes of physical 351 components. 353 4.11. Textual Convention Change 355 Version 1 of the Entity MIB contains three MIB objects defined with the 356 (now obsolete) DisplayString textual convention. In version 2 of the 357 Entity MIB, the syntax for these objects has been updated to use the 358 (now preferred) SnmpAdminString textual convention. 360 The working group realizes that this change is not strictly supported by 361 SMIv2. In our judgment, the alternative of deprecating the old objects 362 and defining new objects would have a more adverse impact on backward 363 compatibility and interoperability, given the particular semantics of 364 these objects. 366 4.12. MIB Structure 368 The Entity MIB contains five groups of MIB objects: 370 - entityPhysical group 371 Describes the physical entities managed by a single agent. 373 - entityLogical group 374 Describes the logical entities managed by a single agent. 376 - entityMapping group 377 Describes the associations between the physical entities, logical 378 entities, interfaces, and non-interface ports managed by a single 379 agent. 381 - entityGeneral group 382 Describes general system attributes shared by potentially all types 383 of entities managed by a single agent. 385 - entityNotifications group 386 Contains status indication notifications. 388 4.12.1. entityPhysical Group 390 This group contains a single table to identify physical system 391 components, called the entPhysicalTable. 393 The entPhysicalTable contains one row per physical entity, and must 394 always contain at least one row for an "overall" physical entity, which 395 should have an entPhysicalClass value of 'stack(11)', 'chassis(3)' or 396 'module(9)'. 398 Each row is indexed by an arbitrary, small integer, and contains a 399 description and type of the physical entity. It also optionally 400 contains the index number of another entPhysicalEntry indicating a 401 containment relationship between the two. 403 Version 2 of the Entity MIB provides additional MIB objects for each 404 physical entity. Some common read-only attributes have been added, as 405 well as three writable string objects. 407 - entPhysicalAlias 408 This string can be used by an NMS as a non-volatile identifier for 409 the physical component. Maintaining a non-volatile string for every 410 physical component represented in the entPhysicalTable can be 411 costly and unnecessary. An agent may algorithmically generate 412 'entPhysicalAlias' strings for particular entries (e.g., based on 413 the entPhysicalClass value). 415 - entPhysicalAssetID 416 This string is provided to store a user-specific asset identifier 417 for removable physical components. In order to reduce the non- 418 volatile storage needed by a particular agent, a network 419 administrator should only assign asset identifiers to physical 420 entities which are field-replaceable (i.e., not permanently 421 contained within another physical entity). 423 - entPhysicalSerialNum 424 This string is provided to store a vendor-specific serial number 425 string for physical components. This is a writable object in case 426 an agent cannot identify the serial numbers of all installed 427 physical entities, and a network administrator wishes to configure 428 the non-volatile serial number strings manually (via an NMS 429 application). 431 4.12.2. entityLogical Group 433 This group contains a single table to identify logical entities, called 434 the entLogicalTable. 436 The entLogicalTable contains one row per logical entity. Each row is 437 indexed by an arbitrary, small integer and contains a name, description, 438 and type of the logical entity. It also contains information to allow 439 access to the MIB information for the logical entity. This includes SNMP 440 versions that use a community name (with some form of implied context 441 representation) and SNMP versions that use the SNMP ARCH [RFC3411] 442 method of context identification. 444 If a agent represents multiple logical entities with this MIB, then this 445 group must be implemented for all logical entities known to the agent. 447 If an agent represents a single logical entity, or multiple logical 448 entities within a single naming scope, then implementation of this group 449 may be omitted by the agent. 451 4.12.3. entityMapping Group 453 This group contains three tables to identify associations between 454 different system components. 456 The entLPMappingTable contains mappings between entLogicalIndex values 457 (logical entities) and entPhysicalIndex values (the physical components 458 supporting that entity). A logical entity can map to more than one 459 physical component, and more than one logical entity can map to (share) 460 the same physical component. If an agent represents a single logical 461 entity, or multiple logical entities within a single naming scope, then 462 implementation of this table may be omitted by the agent. Note that 463 this table is deprecated in version 3 of the Entity MIB. 465 The entAliasMappingTable contains mappings between entLogicalIndex, 466 entPhysicalIndex pairs and 'alias' object identifier values. This 467 allows resources managed with other MIBs (e.g., repeater ports, bridge 468 ports, physical and logical interfaces) to be identified in the physical 469 entity hierarchy. Note that each alias identifier is only relevant in a 470 particular naming scope. If an agent represents a single logical 471 entity, or multiple logical entities within a single naming scope, then 472 implementation of this table may be omitted by the agent. 474 The entPhysicalContainsTable contains simple mappings between 475 'entPhysicalContainedIn' values for each container/'containee' 476 relationship in the managed system. The indexing of this table allows an 477 NMS to quickly discover the 'entPhysicalIndex' values for all children 478 of a given physical entity. 480 4.12.4. entityGeneral Group 482 This group contains general information relating to the other object 483 groups. 485 At this time, the entGeneral group contains a single scalar object 486 (entLastChangeTime), which represents the value of sysUptime when any 487 part of the Entity MIB configuration last changed. 489 4.12.5. entityNotifications Group 491 This group contains notification definitions relating to the overall 492 status of the Entity MIB instantiation. 494 4.13. Multiple Agents 496 Even though a primary motivation for this MIB is to represent the 497 multiple logical entities supported by a single agent, it is also 498 possible to use it to represent multiple logical entities supported by 499 multiple agents (in the same "overall" physical entity). Indeed, it is 500 implicit in the SNMP architecture, that the number of agents is 501 transparent to a network management station. 503 However, there is no agreement at this time as to the degree of 504 cooperation which should be expected for agent implementations. 505 Therefore, multiple agents within the same managed system are free to 506 implement the Entity MIB independently. (Refer the section on "Multiple 507 Instances of the Entity MIB" for more details). 509 4.14. Changes Since RFC 2037 511 4.14.1. Textual Conventions 513 The PhysicalClass TC text has been clarified, and a new enumeration to 514 support 'stackable' components has been added. The SnmpEngineIdOrNone 515 TC has been added to support SNMPv3. 517 4.14.2. New entPhysicalTable Objects 519 The entPhysicalHardwareRev, entPhysicalFirmwareRev, and 520 entPhysicalSoftwareRev objects have been added for revision 521 identification. 523 The entPhysicalSerialNum, entPhysicalMfgName, entPhysicalModelName, and 524 entPhysicalIsFru objects have been added for better vendor 525 identification for physical components. The entPhysicalSerialNum object 526 can be set by a management station in the event the agent cannot 527 identify this information. 529 The entPhysicalAlias and entPhysicalAssetID objects have been added for 530 better user component identification. These objects are intended to be 531 set by a management station and preserved by the agent across restarts. 533 4.14.3. New entLogicalTable Objects 535 The entLogicalContextEngineID and entLogicalContextName objects have 536 been added to provide an SNMP context for SNMPv3 access on behalf of a 537 logical entity. 539 4.14.4. Bugfixes 541 A bug was fixed in the entLogicalCommunity object. The subrange was 542 incorrect (1..255) and is now (0..255). The description clause has also 543 been clarified. This object is now deprecated. 545 The entLastChangeTime object description has been changed to generalize 546 the events which cause an update to the last change timestamp. 548 The syntax was changed from DisplayString to SnmpAdminString for the 549 entPhysicalDescr, entPhysicalName, and entLogicalDescr objects. 551 4.15. Changes Since RFC 2737 553 4.15.1. Textual Conventions 555 The PhysicalIndexOrZero TC has been added to allow objects to reference 556 an entPhysicalIndex value or zero. The PhysicalClass TC has been 557 extended to support a new enumeration for central processing units. 559 4.15.2. Deprecated Objects 561 The entLPMappingTable has been deprecated because no implementations 562 have been found which support this table. The entLPPhysicalIndex has 563 been removed from the entityMappingGroup. This OBJECT-GROUP has been 564 updated (entityMappingGroupRev1) as well as the Entity MIB MODULE- 565 CONFORMANCE statement. 567 4.15.3. Bugfixes 569 The syntax was changed from INTEGER to Integer32 for the 570 entPhysicalParentRelPos, entLogicalIndex, and entAliasLogicalIndexOrZero 571 objects, and from INTEGER to PhysicalIndexOrZero for the 572 entPhysicalContainedIn object. 574 5. Definitions 576 ENTITY-MIB DEFINITIONS ::= BEGIN 578 IMPORTS 579 MODULE-IDENTITY, OBJECT-TYPE, mib-2, NOTIFICATION-TYPE, 580 Integer32 581 FROM SNMPv2-SMI 582 TDomain, TAddress, TEXTUAL-CONVENTION, 583 AutonomousType, RowPointer, TimeStamp, TruthValue 584 FROM SNMPv2-TC 585 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 586 FROM SNMPv2-CONF 587 SnmpAdminString 588 FROM SNMP-FRAMEWORK-MIB; 590 entityMIB MODULE-IDENTITY 591 LAST-UPDATED "200308270000Z" 592 ORGANIZATION "IETF ENTMIB Working Group" 593 CONTACT-INFO 594 " WG E-mail: entmib@ietf.org 595 Mailing list subscription info: 596 http://www.ietf.org/mailman/listinfo/entmib 598 Andy Bierman 599 Cisco Systems Inc. 600 170 West Tasman Drive 601 San Jose, CA 95134 602 +1 408-527-3711 603 abierman@cisco.com 605 Keith McCloghrie 606 Cisco Systems Inc. 607 170 West Tasman Drive 608 San Jose, CA 95134 609 +1 408-526-5260 610 kzm@cisco.com" 612 DESCRIPTION 613 "The MIB module for representing multiple logical 614 entities supported by a single SNMP agent. 616 Copyright (C) The Internet Society (2003). This 617 version of this MIB module is part of RFC xxxx; see 618 the RFC itself for full legal notices." 620 REVISION "200308270000Z" 621 DESCRIPTION 622 "Initial Version of Entity MIB (Version 3). 623 This revision obsoletes RFC 2737. 624 Additions: 625 - cpu(12) enumeration added to PhysicalClass TC 626 - PhysicalIndexOrZero TC 627 Changes: 628 - entLPMappingTable deprecated 629 - entPhysicalContainedIn SYNTAX changed from 630 INTEGER to PhysicalIndexOrZero 632 This version published as RFC xxxx (to be 633 assigned by the RFC Editor)." 634 REVISION "9610310000Z" 635 DESCRIPTION 636 "Initial version (version 1), published as 637 RFC 2037." 638 ::= { mib-2 47 } 640 entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } 642 -- MIB contains four groups 643 entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 } 644 entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 } 645 entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 } 646 entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 } 648 -- Textual Conventions 649 PhysicalIndex ::= TEXTUAL-CONVENTION 650 STATUS current 651 DESCRIPTION 652 "An arbitrary value which uniquely identifies the physical 653 entity. The value should be a small positive integer; index 654 values for different physical entities are not necessarily 655 contiguous." 656 SYNTAX Integer32 (1..2147483647) 658 PhysicalIndexOrZero ::= TEXTUAL-CONVENTION 659 STATUS current 660 DESCRIPTION 661 "This textual convention is an extension of the 662 PhysicalIndex convention which defines a greater than zero 663 value used to identify a physical entity. This extension 664 permits the additional value of zero. The semantics of the 665 value zero are object-specific and must therefore be defined 666 as part of the description of any object which uses this 667 syntax. Examples of the usage of this extension are 668 situations where none or all physical entities need to be 669 referenced." 670 SYNTAX Integer32 (0..2147483647) 672 PhysicalClass ::= TEXTUAL-CONVENTION 673 STATUS current 674 DESCRIPTION 675 "An enumerated value which provides an indication of the 676 general hardware type of a particular physical entity. 677 There are no restrictions as to the number of 678 entPhysicalEntries of each entPhysicalClass, which must be 679 instantiated by an agent. 681 The enumeration 'other' is applicable if the physical entity 682 class is known, but does not match any of the supported 683 values. 685 The enumeration 'unknown' is applicable if the physical 686 entity class is unknown to the agent. 688 The enumeration 'chassis' is applicable if the physical 689 entity class is an overall container for networking 690 equipment. Any class of physical entity except a stack may 691 be contained within a chassis, and a chassis may only be 692 contained within a stack. 694 The enumeration 'backplane' is applicable if the physical 695 entity class is some sort of device for aggregating and 696 forwarding networking traffic, such as a shared backplane in 697 a modular ethernet switch. Note that an agent may model a 698 backplane as a single physical entity, which is actually 699 implemented as multiple discrete physical components (within 700 a chassis or stack). 702 The enumeration 'container' is applicable if the physical 703 entity class is capable of containing one or more removable 704 physical entities, possibly of different types. For example, 705 each (empty or full) slot in a chassis will be modeled as a 706 container. Note that all removable physical entities should 707 be modeled within a container entity, such as field- 708 replaceable modules, fans, or power supplies. Note that all 709 known containers should be modeled by the agent, including 710 empty containers. 712 The enumeration 'powerSupply' is applicable if the physical 713 entity class is a power-supplying component. 715 The enumeration 'fan' is applicable if the physical entity 716 class is a fan or other heat-reduction component. 718 The enumeration 'sensor' is applicable if the physical 719 entity class is some sort of sensor, such as a temperature 720 sensor within a router chassis. 722 The enumeration 'module' is applicable if the physical 723 entity class is some sort of self-contained sub-system. If 724 it is removable, then it should be modeled within a 725 container entity, otherwise it should be modeled directly 726 within another physical entity (e.g., a chassis or another 727 module). 729 The enumeration 'port' is applicable if the physical entity 730 class is some sort of networking port, capable of receiving 731 and/or transmitting networking traffic. 733 The enumeration 'stack' is applicable if the physical entity 734 class is some sort of super-container (possibly virtual), 735 intended to group together multiple chassis entities. A 736 stack may be realized by a 'virtual' cable, a real 737 interconnect cable, attached to multiple chassis, or may in 738 fact be comprised of multiple interconnect cables. A stack 739 should not be modeled within any other physical entities, 740 but a stack may be contained within another stack. Only 741 chassis entities should be contained within a stack. 743 The enumeration 'cpu' is applicable if the physical entity 744 class is some sort of central processing unit." 745 SYNTAX INTEGER { 746 other(1), 747 unknown(2), 748 chassis(3), 749 backplane(4), 750 container(5), -- e.g., chassis slot or daughter-card holder 751 powerSupply(6), 752 fan(7), 753 sensor(8), 754 module(9), -- e.g., plug-in card or daughter-card 755 port(10), 756 stack(11), -- e.g., stack of multiple chassis entities 757 cpu(12) 758 } 760 SnmpEngineIdOrNone ::= TEXTUAL-CONVENTION 761 STATUS current 762 DESCRIPTION 763 "A specially formatted SnmpEngineID string for use with the 764 Entity MIB. 766 If an instance of an object of SYNTAX SnmpEngineIdOrNone has 767 a non-zero length, then the object encoding and semantics 768 are defined by the SnmpEngineID textual convention (see STD 769 62, RFC 3411 [RFC3411]). 771 If an instance of an object of SYNTAX SnmpEngineIdOrNone 772 contains a zero-length string, then no appropriate 773 SnmpEngineID is associated with the logical entity (i.e., 774 SNMPv3 not supported)." 775 SYNTAX OCTET STRING (SIZE(0..32)) -- empty string or SnmpEngineID 777 -- The Physical Entity Table 778 entPhysicalTable OBJECT-TYPE 779 SYNTAX SEQUENCE OF EntPhysicalEntry 780 MAX-ACCESS not-accessible 781 STATUS current 782 DESCRIPTION 783 "This table contains one row per physical entity. There is 784 always at least one row for an 'overall' physical entity." 785 ::= { entityPhysical 1 } 787 entPhysicalEntry OBJECT-TYPE 788 SYNTAX EntPhysicalEntry 789 MAX-ACCESS not-accessible 790 STATUS current 791 DESCRIPTION 792 "Information about a particular physical entity. 794 Each entry provides objects (entPhysicalDescr, 795 entPhysicalVendorType, and entPhysicalClass) to help an NMS 796 identify and characterize the entry, and objects 797 (entPhysicalContainedIn and entPhysicalParentRelPos) to help 798 an NMS relate the particular entry to other entries in this 799 table." 800 INDEX { entPhysicalIndex } 801 ::= { entPhysicalTable 1 } 803 EntPhysicalEntry ::= SEQUENCE { 804 entPhysicalIndex PhysicalIndex, 805 entPhysicalDescr SnmpAdminString, 806 entPhysicalVendorType AutonomousType, 807 entPhysicalContainedIn PhysicalIndexOrZero, 808 entPhysicalClass PhysicalClass, 809 entPhysicalParentRelPos Integer32, 810 entPhysicalName SnmpAdminString, 811 entPhysicalHardwareRev SnmpAdminString, 812 entPhysicalFirmwareRev SnmpAdminString, 813 entPhysicalSoftwareRev SnmpAdminString, 814 entPhysicalSerialNum SnmpAdminString, 815 entPhysicalMfgName SnmpAdminString, 816 entPhysicalModelName SnmpAdminString, 817 entPhysicalAlias SnmpAdminString, 818 entPhysicalAssetID SnmpAdminString, 819 entPhysicalIsFRU TruthValue 820 } 822 entPhysicalIndex OBJECT-TYPE 823 SYNTAX PhysicalIndex 824 MAX-ACCESS not-accessible 825 STATUS current 826 DESCRIPTION 827 "The index for this entry." 828 ::= { entPhysicalEntry 1 } 830 entPhysicalDescr OBJECT-TYPE 831 SYNTAX SnmpAdminString 832 MAX-ACCESS read-only 833 STATUS current 834 DESCRIPTION 835 "A textual description of physical entity. This object 836 should contain a string which identifies the manufacturer's 837 name for the physical entity, and should be set to a 838 distinct value for each version or model of the physical 839 entity. " 840 ::= { entPhysicalEntry 2 } 842 entPhysicalVendorType OBJECT-TYPE 843 SYNTAX AutonomousType 844 MAX-ACCESS read-only 845 STATUS current 846 DESCRIPTION 847 "An indication of the vendor-specific hardware type of the 848 physical entity. Note that this is different from the 849 definition of MIB-II's sysObjectID. 851 An agent should set this object to a enterprise-specific 852 registration identifier value indicating the specific 853 equipment type in detail. The associated instance of 854 entPhysicalClass is used to indicate the general type of 855 hardware device. 857 If no vendor-specific registration identifier exists for 858 this physical entity, or the value is unknown by this agent, 859 then the value { 0 0 } is returned." 860 ::= { entPhysicalEntry 3 } 862 entPhysicalContainedIn OBJECT-TYPE 863 SYNTAX PhysicalIndexOrZero 864 MAX-ACCESS read-only 865 STATUS current 866 DESCRIPTION 867 "The value of entPhysicalIndex for the physical entity which 868 'contains' this physical entity. A value of zero indicates 869 this physical entity is not contained in any other physical 870 entity. Note that the set of 'containment' relationships 871 define a strict hierarchy; that is, recursion is not 872 allowed. 874 In the event a physical entity is contained by more than one 875 physical entity (e.g., double-wide modules), this object 876 should identify the containing entity with the lowest value 877 of entPhysicalIndex." 878 ::= { entPhysicalEntry 4 } 880 entPhysicalClass OBJECT-TYPE 881 SYNTAX PhysicalClass 882 MAX-ACCESS read-only 883 STATUS current 884 DESCRIPTION 885 "An indication of the general hardware type of the physical 886 entity. 888 An agent should set this object to the standard enumeration 889 value which most accurately indicates the general class of 890 the physical entity, or the primary class if there is more 891 than one. 893 If no appropriate standard registration identifier exists 894 for this physical entity, then the value 'other(1)' is 895 returned. If the value is unknown by this agent, then the 896 value 'unknown(2)' is returned." 897 ::= { entPhysicalEntry 5 } 899 entPhysicalParentRelPos OBJECT-TYPE 900 SYNTAX Integer32 (-1..2147483647) 901 MAX-ACCESS read-only 902 STATUS current 903 DESCRIPTION 904 "An indication of the relative position of this 'child' 905 component among all its 'sibling' components. Sibling 906 components are defined as entPhysicalEntries which share the 907 same instance values of each of the entPhysicalContainedIn 908 and entPhysicalClass objects. 910 An NMS can use this object to identify the relative ordering 911 for all sibling components of a particular parent 912 (identified by the entPhysicalContainedIn instance in each 913 sibling entry). 915 This value should match any external labeling of the 916 physical component if possible. For example, for a container 917 (e.g., card slot) labeled as 'slot #3', 918 entPhysicalParentRelPos should have the value '3'. Note 919 that the entPhysicalEntry for the module plugged in slot 3 920 should have an entPhysicalParentRelPos value of '1'. 922 If the physical position of this component does not match 923 any external numbering or clearly visible ordering, then 924 user documentation or other external reference material 925 should be used to determine the parent-relative position. If 926 this is not possible, then the the agent should assign a 927 consistent (but possibly arbitrary) ordering to a given set 928 of 'sibling' components, perhaps based on internal 929 representation of the components. 931 If the agent cannot determine the parent-relative position 932 for some reason, or if the associated value of 933 entPhysicalContainedIn is '0', then the value '-1' is 934 returned. Otherwise a non-negative integer is returned, 935 indicating the parent-relative position of this physical 936 entity. 938 Parent-relative ordering normally starts from '1' and 939 continues to 'N', where 'N' represents the highest 940 positioned child entity. However, if the physical entities 941 (e.g., slots) are labeled from a starting position of zero, 942 then the first sibling should be associated with a 943 entPhysicalParentRelPos value of '0'. Note that this 944 ordering may be sparse or dense, depending on agent 945 implementation. 947 The actual values returned are not globally meaningful, as 948 each 'parent' component may use different numbering 949 algorithms. The ordering is only meaningful among siblings 950 of the same parent component. 952 The agent should retain parent-relative position values 953 across reboots, either through algorithmic assignment or use 954 of non-volatile storage." 955 ::= { entPhysicalEntry 6 } 957 entPhysicalName OBJECT-TYPE 958 SYNTAX SnmpAdminString 959 MAX-ACCESS read-only 960 STATUS current 961 DESCRIPTION 962 "The textual name of the physical entity. The value of this 963 object should be the name of the component as assigned by 964 the local device and should be suitable for use in commands 965 entered at the device's `console'. This might be a text 966 name, such as `console' or a simple component number (e.g., 967 port or module number), such as `1', depending on the 968 physical component naming syntax of the device. 970 If there is no local name, or this object is otherwise not 971 applicable, then this object contains a zero-length string. 973 Note that the value of entPhysicalName for two physical 974 entities will be the same in the event that the console 975 interface does not distinguish between them, e.g., slot-1 976 and the card in slot-1." 977 ::= { entPhysicalEntry 7 } 979 entPhysicalHardwareRev OBJECT-TYPE 980 SYNTAX SnmpAdminString 981 MAX-ACCESS read-only 982 STATUS current 983 DESCRIPTION 984 "The vendor-specific hardware revision string for the 985 physical entity. The preferred value is the hardware 986 revision identifier actually printed on the component itself 987 (if present). 989 Note that if revision information is stored internally in a 990 non-printable (e.g., binary) format, then the agent must 991 convert such information to a printable format, in an 992 implementation-specific manner. 994 If no specific hardware revision string is associated with 995 the physical component, or this information is unknown to 996 the agent, then this object will contain a zero-length 997 string." 998 ::= { entPhysicalEntry 8 } 1000 entPhysicalFirmwareRev OBJECT-TYPE 1001 SYNTAX SnmpAdminString 1002 MAX-ACCESS read-only 1003 STATUS current 1004 DESCRIPTION 1005 "The vendor-specific firmware revision string for the 1006 physical entity. 1008 Note that if revision information is stored internally in a 1009 non-printable (e.g., binary) format, then the agent must 1010 convert such information to a printable format, in an 1011 implementation-specific manner. 1013 If no specific firmware programs are associated with the 1014 physical component, or this information is unknown to the 1015 agent, then this object will contain a zero-length string." 1016 ::= { entPhysicalEntry 9 } 1018 entPhysicalSoftwareRev OBJECT-TYPE 1019 SYNTAX SnmpAdminString 1020 MAX-ACCESS read-only 1021 STATUS current 1022 DESCRIPTION 1023 "The vendor-specific software revision string for the 1024 physical entity. 1026 Note that if revision information is stored internally in a 1027 non-printable (e.g., binary) format, then the agent must 1028 convert such information to a printable format, in an 1029 implementation-specific manner. 1031 If no specific software programs are associated with the 1032 physical component, or this information is unknown to the 1033 agent, then this object will contain a zero-length string." 1034 ::= { entPhysicalEntry 10 } 1036 entPhysicalSerialNum OBJECT-TYPE 1037 SYNTAX SnmpAdminString (SIZE (0..32)) 1038 MAX-ACCESS read-write 1039 STATUS current 1040 DESCRIPTION 1041 "The vendor-specific serial number string for the physical 1042 entity. The preferred value is the serial number string 1043 actually printed on the component itself (if present). 1045 On the first instantiation of an physical entity, the value 1046 of entPhysicalSerialNum associated with that entity is set 1047 to the correct vendor-assigned serial number, if this 1048 information is available to the agent. If a serial number 1049 is unknown or non-existent, the entPhysicalSerialNum will be 1050 set to a zero-length string instead. 1052 Note that implementations which can correctly identify the 1053 serial numbers of all installed physical entities do not 1054 need to provide write access to the entPhysicalSerialNum 1055 object. Agents which cannot provide non-volatile storage for 1056 the entPhysicalSerialNum strings are not required to 1057 implement write access for this object. 1059 Not every physical component will have a serial number, or 1060 even need one. Physical entities for which the associated 1061 value of the entPhysicalIsFRU object is equal to 'false(2)' 1062 (e.g., the repeater ports within a repeater module), do not 1063 need their own unique serial number. An agent does not have 1064 to provide write access for such entities, and may return a 1065 zero-length string. 1067 If write access is implemented for an instance of 1068 entPhysicalSerialNum, and a value is written into the 1069 instance, the agent must retain the supplied value in the 1070 entPhysicalSerialNum instance associated with the same 1071 physical entity for as long as that entity remains 1072 instantiated. This includes instantiations across all re- 1073 initializations/reboots of the network management system, 1074 including those which result in a change of the physical 1075 entity's entPhysicalIndex value." 1076 ::= { entPhysicalEntry 11 } 1078 entPhysicalMfgName OBJECT-TYPE 1079 SYNTAX SnmpAdminString 1080 MAX-ACCESS read-only 1081 STATUS current 1082 DESCRIPTION 1083 "The name of the manufacturer of this physical component. 1084 The preferred value is the manufacturer name string actually 1085 printed on the component itself (if present). 1087 Note that comparisons between instances of the 1088 entPhysicalModelName, entPhysicalFirmwareRev, 1089 entPhysicalSoftwareRev, and the entPhysicalSerialNum 1090 objects, are only meaningful amongst entPhysicalEntries with 1091 the same value of entPhysicalMfgName. 1093 If the manufacturer name string associated with the physical 1094 component is unknown to the agent, then this object will 1095 contain a zero-length string." 1096 ::= { entPhysicalEntry 12 } 1098 entPhysicalModelName OBJECT-TYPE 1099 SYNTAX SnmpAdminString 1100 MAX-ACCESS read-only 1101 STATUS current 1102 DESCRIPTION 1103 "The vendor-specific model name identifier string associated 1104 with this physical component. The preferred value is the 1105 customer-visible part number, which may be printed on the 1106 component itself. 1108 If the model name string associated with the physical 1109 component is unknown to the agent, then this object will 1110 contain a zero-length string." 1111 ::= { entPhysicalEntry 13 } 1113 entPhysicalAlias OBJECT-TYPE 1114 SYNTAX SnmpAdminString (SIZE (0..32)) 1115 MAX-ACCESS read-write 1116 STATUS current 1117 DESCRIPTION 1118 "This object is an 'alias' name for the physical entity as 1119 specified by a network manager, and provides a non-volatile 1120 'handle' for the physical entity. 1122 On the first instantiation of an physical entity, the value 1123 of entPhysicalAlias associated with that entity is set to 1124 the zero-length string. However, agent may set the value to 1125 a locally unique default value, instead of a zero-length 1126 string. 1128 If write access is implemented for an instance of 1129 entPhysicalAlias, and a value is written into the instance, 1130 the agent must retain the supplied value in the 1131 entPhysicalAlias instance associated with the same physical 1132 entity for as long as that entity remains instantiated. 1133 This includes instantiations across all re- 1134 initializations/reboots of the network management system, 1135 including those which result in a change of the physical 1136 entity's entPhysicalIndex value." 1137 ::= { entPhysicalEntry 14 } 1139 entPhysicalAssetID OBJECT-TYPE 1140 SYNTAX SnmpAdminString (SIZE (0..32)) 1141 MAX-ACCESS read-write 1142 STATUS current 1143 DESCRIPTION 1144 "This object is a user-assigned asset tracking identifier 1145 for the physical entity as specified by a network manager, 1146 and provides non-volatile storage of this information. 1148 On the first instantiation of an physical entity, the value 1149 of entPhysicalAssetID associated with that entity is set to 1150 the zero-length string. 1152 Not every physical component will have a asset tracking 1153 identifier, or even need one. Physical entities for which 1154 the associated value of the entPhysicalIsFRU object is equal 1155 to 'false(2)' (e.g., the repeater ports within a repeater 1156 module), do not need their own unique asset tracking 1157 identifier. An agent does not have to provide write access 1158 for such entities, and may instead return a zero-length 1159 string. 1161 If write access is implemented for an instance of 1162 entPhysicalAssetID, and a value is written into the 1163 instance, the agent must retain the supplied value in the 1164 entPhysicalAssetID instance associated with the same 1165 physical entity for as long as that entity remains 1166 instantiated. This includes instantiations across all re- 1167 initializations/reboots of the network management system, 1168 including those which result in a change of the physical 1169 entity's entPhysicalIndex value. 1171 If no asset tracking information is associated with the 1172 physical component, then this object will contain a zero- 1173 length string." 1174 ::= { entPhysicalEntry 15 } 1176 entPhysicalIsFRU OBJECT-TYPE 1177 SYNTAX TruthValue 1178 MAX-ACCESS read-only 1179 STATUS current 1180 DESCRIPTION 1181 "This object indicates whether or not this physical entity 1182 is considered a 'field replaceable unit' by the vendor. If 1183 this object contains the value 'true(1)' then this 1184 entPhysicalEntry identifies a field replaceable unit. For 1185 all entPhysicalEntries which represent components that are 1186 permanently contained within a field replaceable unit, the 1187 value 'false(2)' should be returned for this object." 1188 ::= { entPhysicalEntry 16 } 1190 -- The Logical Entity Table 1191 entLogicalTable OBJECT-TYPE 1192 SYNTAX SEQUENCE OF EntLogicalEntry 1193 MAX-ACCESS not-accessible 1194 STATUS current 1195 DESCRIPTION 1196 "This table contains one row per logical entity. For agents 1197 which implement more than one naming scope, at least one 1198 entry must exist. Agents which instantiate all MIB objects 1199 within a single naming scope are not required to implement 1200 this table." 1201 ::= { entityLogical 1 } 1203 entLogicalEntry OBJECT-TYPE 1204 SYNTAX EntLogicalEntry 1205 MAX-ACCESS not-accessible 1206 STATUS current 1207 DESCRIPTION 1208 "Information about a particular logical entity. Entities 1209 may be managed by this agent or other SNMP agents (possibly) 1210 in the same chassis." 1211 INDEX { entLogicalIndex } 1212 ::= { entLogicalTable 1 } 1214 EntLogicalEntry ::= SEQUENCE { 1215 entLogicalIndex Integer32, 1216 entLogicalDescr SnmpAdminString, 1217 entLogicalType AutonomousType, 1218 entLogicalCommunity OCTET STRING, 1219 entLogicalTAddress TAddress, 1220 entLogicalTDomain TDomain, 1221 entLogicalContextEngineID SnmpEngineIdOrNone, 1222 entLogicalContextName SnmpAdminString 1223 } 1225 entLogicalIndex OBJECT-TYPE 1226 SYNTAX Integer32 (1..2147483647) 1227 MAX-ACCESS not-accessible 1228 STATUS current 1229 DESCRIPTION 1230 "The value of this object uniquely identifies the logical 1231 entity. The value should be a small positive integer; index 1232 values for different logical entities are are not 1233 necessarily contiguous." 1234 ::= { entLogicalEntry 1 } 1236 entLogicalDescr OBJECT-TYPE 1237 SYNTAX SnmpAdminString 1238 MAX-ACCESS read-only 1239 STATUS current 1240 DESCRIPTION 1241 "A textual description of the logical entity. This object 1242 should contain a string which identifies the manufacturer's 1243 name for the logical entity, and should be set to a distinct 1244 value for each version of the logical entity. " 1245 ::= { entLogicalEntry 2 } 1247 entLogicalType OBJECT-TYPE 1248 SYNTAX AutonomousType 1249 MAX-ACCESS read-only 1250 STATUS current 1251 DESCRIPTION 1252 "An indication of the type of logical entity. This will 1253 typically be the OBJECT IDENTIFIER name of the node in the 1254 SMI's naming hierarchy which represents the major MIB 1255 module, or the majority of the MIB modules, supported by the 1256 logical entity. For example: 1257 a logical entity of a regular host/router -> mib-2 1258 a logical entity of a 802.1d bridge -> dot1dBridge 1259 a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt 1260 If an appropriate node in the SMI's naming hierarchy cannot 1261 be identified, the value 'mib-2' should be used." 1262 ::= { entLogicalEntry 3 } 1264 entLogicalCommunity OBJECT-TYPE 1265 SYNTAX OCTET STRING (SIZE (0..255)) 1266 MAX-ACCESS read-only 1267 STATUS deprecated 1268 DESCRIPTION 1269 "An SNMPv1 or SNMPv2C community-string which can be used to 1270 access detailed management information for this logical 1271 entity. The agent should allow read access with this 1272 community string (to an appropriate subset of all managed 1273 objects) and may also return a community string based on the 1274 privileges of the request used to read this object. Note 1275 that an agent may return a community string with read-only 1276 privileges, even if this object is accessed with a read- 1277 write community string. However, the agent must take care 1278 not to return a community string which allows more 1279 privileges than the community string used to access this 1280 object. 1282 A compliant SNMP agent may wish to conserve naming scopes by 1283 representing multiple logical entities in a single 'default' 1284 naming scope. This is possible when the logical entities 1285 represented by the same value of entLogicalCommunity have no 1286 object instances in common. For example, 'bridge1' and 1287 'repeater1' may be part of the main naming scope, but at 1288 least one additional community string is needed to represent 1289 'bridge2' and 'repeater2'. 1291 Logical entities 'bridge1' and 'repeater1' would be 1292 represented by sysOREntries associated with the 'default' 1293 naming scope. 1295 For agents not accessible via SNMPv1 or SNMPv2C, the value 1296 of this object is the empty string. This object may also 1297 contain an empty string if a community string has not yet 1298 been assigned by the agent, or no community string with 1299 suitable access rights can be returned for a particular SNMP 1300 request. 1302 Note that this object is deprecated. Agents which implement 1303 SNMPv3 access should use the entLogicalContextEngineID and 1304 entLogicalContextName objects to identify the context 1305 associated with each logical entity. SNMPv3 agents may 1306 return a zero-length string for this object, or may continue 1307 to return a community string (e.g., tri-lingual agent 1308 support)." 1309 ::= { entLogicalEntry 4 } 1311 entLogicalTAddress OBJECT-TYPE 1312 SYNTAX TAddress 1313 MAX-ACCESS read-only 1314 STATUS current 1315 DESCRIPTION 1316 "The transport service address by which the logical entity 1317 receives network management traffic, formatted according to 1318 the corresponding value of entLogicalTDomain. 1320 For snmpUDPDomain, a TAddress is 6 octets long, the initial 1321 4 octets containing the IP-address in network-byte order and 1322 the last 2 containing the UDP port in network-byte order. 1323 Consult 'Transport Mappings for the Simple Network 1324 Management Protocol' (STD 62, RFC 3417 [RFC3417]) for 1325 further information on snmpUDPDomain." 1326 ::= { entLogicalEntry 5 } 1328 entLogicalTDomain OBJECT-TYPE 1329 SYNTAX TDomain 1330 MAX-ACCESS read-only 1331 STATUS current 1332 DESCRIPTION 1333 "Indicates the kind of transport service by which the 1334 logical entity receives network management traffic. 1335 Possible values for this object are presently found in the 1336 Transport Mappings for Simple Network Management Protocol' 1337 (STD 62, RFC 3417 [RFC3417])." 1339 ::= { entLogicalEntry 6 } 1341 entLogicalContextEngineID OBJECT-TYPE 1342 SYNTAX SnmpEngineIdOrNone 1343 MAX-ACCESS read-only 1344 STATUS current 1345 DESCRIPTION 1346 "The authoritative contextEngineID that can be used to send 1347 an SNMP message concerning information held by this logical 1348 entity, to the address specified by the associated 1349 'entLogicalTAddress/entLogicalTDomain' pair. 1351 This object, together with the associated 1352 entLogicalContextName object, defines the context associated 1353 with a particular logical entity, and allows access to SNMP 1354 engines identified by a contextEngineId and contextName 1355 pair. 1357 If no value has been configured by the agent, a zero-length 1358 string is returned, or the agent may choose not to 1359 instantiate this object at all." 1360 ::= { entLogicalEntry 7 } 1362 entLogicalContextName OBJECT-TYPE 1363 SYNTAX SnmpAdminString 1364 MAX-ACCESS read-only 1365 STATUS current 1366 DESCRIPTION 1367 "The contextName that can be used to send an SNMP message 1368 concerning information held by this logical entity, to the 1369 address specified by the associated 1370 'entLogicalTAddress/entLogicalTDomain' pair. 1372 This object, together with the associated 1373 entLogicalContextEngineID object, defines the context 1374 associated with a particular logical entity, and allows 1375 access to SNMP engines identified by a contextEngineId and 1376 contextName pair. 1378 If no value has been configured by the agent, a zero-length 1379 string is returned, or the agent may choose not to 1380 instantiate this object at all." 1381 ::= { entLogicalEntry 8 } 1383 entLPMappingTable OBJECT-TYPE 1384 SYNTAX SEQUENCE OF EntLPMappingEntry 1385 MAX-ACCESS not-accessible 1386 STATUS deprecated 1387 DESCRIPTION 1388 "This table contains zero or more rows of logical entity to 1389 physical equipment associations. For each logical entity 1390 known by this agent, there are zero or more mappings to the 1391 physical resources which are used to realize that logical 1392 entity. 1394 An agent should limit the number and nature of entries in 1395 this table such that only meaningful and non-redundant 1396 information is returned. For example, in a system which 1397 contains a single power supply, mappings between logical 1398 entities and the power supply are not useful and should not 1399 be included. 1401 Also, only the most appropriate physical component which is 1402 closest to the root of a particular containment tree should 1403 be identified in an entLPMapping entry. 1405 For example, suppose a bridge is realized on a particular 1406 module, and all ports on that module are ports on this 1407 bridge. A mapping between the bridge and the module would be 1408 useful, but additional mappings between the bridge and each 1409 of the ports on that module would be redundant (since the 1410 entPhysicalContainedIn hierarchy can provide the same 1411 information). If, on the other hand, more than one bridge 1412 was utilizing ports on this module, then mappings between 1413 each bridge and the ports it used would be appropriate. 1415 Also, in the case of a single backplane repeater, a mapping 1416 for the backplane to the single repeater entity is not 1417 necessary." 1418 ::= { entityMapping 1 } 1420 entLPMappingEntry OBJECT-TYPE 1421 SYNTAX EntLPMappingEntry 1422 MAX-ACCESS not-accessible 1423 STATUS deprecated 1424 DESCRIPTION 1425 "Information about a particular logical entity to physical 1426 equipment association. Note that the nature of the 1427 association is not specifically identified in this entry. 1428 It is expected that sufficient information exists in the 1429 MIBs used to manage a particular logical entity to infer how 1430 physical component information is utilized." 1431 INDEX { entLogicalIndex, entLPPhysicalIndex } 1432 ::= { entLPMappingTable 1 } 1434 EntLPMappingEntry ::= SEQUENCE { 1435 entLPPhysicalIndex PhysicalIndex 1436 } 1438 entLPPhysicalIndex OBJECT-TYPE 1439 SYNTAX PhysicalIndex 1440 MAX-ACCESS read-only 1441 STATUS deprecated 1442 DESCRIPTION 1443 "The value of this object identifies the index value of a 1444 particular entPhysicalEntry associated with the indicated 1445 entLogicalEntity." 1446 ::= { entLPMappingEntry 1 } 1448 -- logical entity/component to alias table 1449 entAliasMappingTable OBJECT-TYPE 1450 SYNTAX SEQUENCE OF EntAliasMappingEntry 1451 MAX-ACCESS not-accessible 1452 STATUS current 1453 DESCRIPTION 1454 "This table contains zero or more rows, representing 1455 mappings of logical entity and physical component to 1456 external MIB identifiers. Each physical port in the system 1457 may be associated with a mapping to an external identifier, 1458 which itself is associated with a particular logical 1459 entity's naming scope. A 'wildcard' mechanism is provided 1460 to indicate that an identifier is associated with more than 1461 one logical entity." 1462 ::= { entityMapping 2 } 1464 entAliasMappingEntry OBJECT-TYPE 1465 SYNTAX EntAliasMappingEntry 1466 MAX-ACCESS not-accessible 1467 STATUS current 1468 DESCRIPTION 1469 "Information about a particular physical equipment, logical 1470 entity to external identifier binding. Each logical 1471 entity/physical component pair may be associated with one 1472 alias mapping. The logical entity index may also be used as 1473 a 'wildcard' (refer to the entAliasLogicalIndexOrZero object 1474 DESCRIPTION clause for details.) 1476 Note that only entPhysicalIndex values which represent 1477 physical ports (i.e. associated entPhysicalClass value is 1478 'port(10)') are permitted to exist in this table." 1479 INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero } 1480 ::= { entAliasMappingTable 1 } 1482 EntAliasMappingEntry ::= SEQUENCE { 1483 entAliasLogicalIndexOrZero Integer32, 1484 entAliasMappingIdentifier RowPointer 1485 } 1487 entAliasLogicalIndexOrZero OBJECT-TYPE 1488 SYNTAX Integer32 (0..2147483647) 1489 MAX-ACCESS not-accessible 1490 STATUS current 1491 DESCRIPTION 1492 "The value of this object identifies the logical entity 1493 which defines the naming scope for the associated instance 1494 of the 'entAliasMappingIdentifier' object. 1496 If this object has a non-zero value, then it identifies the 1497 logical entity named by the same value of entLogicalIndex. 1499 If this object has a value of zero, then the mapping between 1500 the physical component and the alias identifier for this 1501 entAliasMapping entry is associated with all unspecified 1502 logical entities. That is, a value of zero (the default 1503 mapping) identifies any logical entity which does not have 1504 an explicit entry in this table for a particular 1505 entPhysicalIndex/entAliasMappingIdentifier pair. 1507 For example, to indicate that a particular interface (e.g., 1508 physical component 33) is identified by the same value of 1509 ifIndex for all logical entities, the following instance 1510 might exist: 1512 entAliasMappingIdentifier.33.0 = ifIndex.5 1514 In the event an entPhysicalEntry is associated differently 1515 for some logical entities, additional entAliasMapping 1516 entries may exist, e.g.: 1518 entAliasMappingIdentifier.33.0 = ifIndex.6 1519 entAliasMappingIdentifier.33.4 = ifIndex.1 1520 entAliasMappingIdentifier.33.5 = ifIndex.1 1521 entAliasMappingIdentifier.33.10 = ifIndex.12 1523 Note that entries with non-zero entAliasLogicalIndexOrZero 1524 index values have precedence over any zero-indexed entry. In 1525 this example, all logical entities except 4, 5, and 10, 1526 associate physical entity 33 with ifIndex.6." 1527 ::= { entAliasMappingEntry 1 } 1529 entAliasMappingIdentifier OBJECT-TYPE 1530 SYNTAX RowPointer 1531 MAX-ACCESS read-only 1532 STATUS current 1533 DESCRIPTION 1534 "The value of this object identifies a particular conceptual 1535 row associated with the indicated entPhysicalIndex and 1536 entLogicalIndex pair. 1538 Since only physical ports are modeled in this table, only 1539 entries which represent interfaces or ports are allowed. If 1540 an ifEntry exists on behalf of a particular physical port, 1541 then this object should identify the associated 'ifEntry'. 1542 For repeater ports, the appropriate row in the 1543 'rptrPortGroupTable' should be identified instead. 1545 For example, suppose a physical port was represented by 1546 entPhysicalEntry.3, entLogicalEntry.15 existed for a 1547 repeater, and entLogicalEntry.22 existed for a bridge. Then 1548 there might be two related instances of 1549 entAliasMappingIdentifier: 1550 entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2 1551 entAliasMappingIdentifier.3.22 == ifIndex.17 1552 It is possible that other mappings (besides interfaces and 1553 repeater ports) may be defined in the future, as required. 1555 Bridge ports are identified by examining the Bridge MIB and 1556 appropriate ifEntries associated with each 'dot1dBasePort', 1557 and are thus not represented in this table." 1558 ::= { entAliasMappingEntry 2 } 1560 -- physical mapping table 1561 entPhysicalContainsTable OBJECT-TYPE 1562 SYNTAX SEQUENCE OF EntPhysicalContainsEntry 1563 MAX-ACCESS not-accessible 1564 STATUS current 1565 DESCRIPTION 1566 "A table which exposes the container/'containee' 1567 relationships between physical entities. This table provides 1568 all the information found by constructing the virtual 1569 containment tree for a given entPhysicalTable, but in a more 1570 direct format. 1572 In the event a physical entity is contained by more than one 1573 other physical entity (e.g., double-wide modules), this 1574 table should include these additional mappings, which cannot 1575 be represented in the entPhysicalTable virtual containment 1576 tree." 1577 ::= { entityMapping 3 } 1579 entPhysicalContainsEntry OBJECT-TYPE 1580 SYNTAX EntPhysicalContainsEntry 1581 MAX-ACCESS not-accessible 1582 STATUS current 1583 DESCRIPTION 1584 "A single container/'containee' relationship." 1585 INDEX { entPhysicalIndex, entPhysicalChildIndex } 1586 ::= { entPhysicalContainsTable 1 } 1588 EntPhysicalContainsEntry ::= SEQUENCE { 1589 entPhysicalChildIndex PhysicalIndex 1590 } 1592 entPhysicalChildIndex OBJECT-TYPE 1593 SYNTAX PhysicalIndex 1594 MAX-ACCESS read-only 1595 STATUS current 1596 DESCRIPTION 1597 "The value of entPhysicalIndex for the contained physical 1598 entity." 1599 ::= { entPhysicalContainsEntry 1 } 1601 -- last change time stamp for the whole MIB 1602 entLastChangeTime OBJECT-TYPE 1603 SYNTAX TimeStamp 1604 MAX-ACCESS read-only 1605 STATUS current 1606 DESCRIPTION 1607 "The value of sysUpTime at the time a conceptual row is 1608 created, modified, or deleted in any of these tables: 1609 - entPhysicalTable 1610 - entLogicalTable 1611 - entLPMappingTable 1612 - entAliasMappingTable 1613 - entPhysicalContainsTable 1614 " 1615 ::= { entityGeneral 1 } 1617 -- Entity MIB Trap Definitions 1618 entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } 1619 entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } 1621 entConfigChange NOTIFICATION-TYPE 1622 STATUS current 1623 DESCRIPTION 1624 "An entConfigChange notification is generated when the value 1625 of entLastChangeTime changes. It can be utilized by an NMS 1626 to trigger logical/physical entity table maintenance polls. 1628 An agent should not generate more than one entConfigChange 1629 'notification-event' in a given time interval (five seconds 1630 is the suggested default). A 'notification-event' is the 1631 transmission of a single trap or inform PDU to a list of 1632 notification destinations. 1634 If additional configuration changes occur within the 1635 throttling period, then notification-events for these 1636 changes should be suppressed by the agent until the current 1637 throttling period expires. At the end of a throttling 1638 period, one notification-event should be generated if any 1639 configuration changes occurred since the start of the 1640 throttling period. In such a case, another throttling period 1641 is started right away. 1643 An NMS should periodically check the value of 1644 entLastChangeTime to detect any missed entConfigChange 1645 notification-events, e.g., due to throttling or transmission 1646 loss." 1647 ::= { entityMIBTrapPrefix 1 } 1649 -- conformance information 1650 entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } 1652 entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } 1653 entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } 1655 -- compliance statements 1656 entityCompliance MODULE-COMPLIANCE 1657 STATUS deprecated 1658 DESCRIPTION 1659 "The compliance statement for SNMP entities which implement 1660 version 1 of the Entity MIB." 1661 MODULE -- this module 1662 MANDATORY-GROUPS { 1663 entityPhysicalGroup, 1664 entityLogicalGroup, 1665 entityMappingGroup, 1666 entityGeneralGroup, 1667 entityNotificationsGroup 1668 } 1669 ::= { entityCompliances 1 } 1671 entity2Compliance MODULE-COMPLIANCE 1672 STATUS deprecated 1673 DESCRIPTION 1674 "The compliance statement for SNMP entities which implement 1675 version 2 of the Entity MIB." 1676 MODULE -- this module 1677 MANDATORY-GROUPS { 1678 entityPhysicalGroup, 1679 entityPhysical2Group, 1680 entityGeneralGroup, 1681 entityNotificationsGroup 1682 } 1683 GROUP entityLogical2Group 1684 DESCRIPTION 1685 "Implementation of this group is not mandatory for agents 1686 which model all MIB object instances within a single naming 1687 scope." 1689 GROUP entityMappingGroup 1690 DESCRIPTION 1691 "Implementation of the entPhysicalContainsTable is mandatory 1692 for all agents. Implementation of the entLPMappingTable and 1693 entAliasMappingTables are not mandatory for agents which 1694 model all MIB object instances within a single naming scope. 1696 Note that the entAliasMappingTable may be useful for all 1697 agents, however implementation of the entityLogicalGroup or 1698 entityLogical2Group is required to support this table." 1700 OBJECT entPhysicalSerialNum 1701 MIN-ACCESS not-accessible 1702 DESCRIPTION 1703 "Read and write access is not required for agents which 1704 cannot identify serial number information for physical 1705 entities, and/or cannot provide non-volatile storage for 1706 NMS-assigned serial numbers. 1708 Write access is not required for agents which can identify 1709 serial number information for physical entities, but cannot 1710 provide non-volatile storage for NMS-assigned serial 1711 numbers. 1713 Write access is not required for physical entities for 1714 physical entities for which the associated value of the 1715 entPhysicalIsFRU object is equal to 'false(2)'." 1717 OBJECT entPhysicalAlias 1718 MIN-ACCESS read-only 1719 DESCRIPTION 1720 "Write access is required only if the associated 1721 entPhysicalClass value is equal to 'chassis(3)'." 1723 OBJECT entPhysicalAssetID 1724 MIN-ACCESS not-accessible 1725 DESCRIPTION 1726 "Read and write access is not required for agents which 1727 cannot provide non-volatile storage for NMS-assigned asset 1728 identifiers. 1730 Write access is not required for physical entities for which 1731 the associated value of entPhysicalIsFRU is equal to 1732 'false(2)'." 1734 OBJECT entPhysicalClass 1735 SYNTAX INTEGER { 1736 other(1), 1737 unknown(2), 1738 chassis(3), 1739 backplane(4), 1740 container(5), 1741 powerSupply(6), 1742 fan(7), 1743 sensor(8), 1744 module(9), 1745 port(10), 1746 stack(11) 1747 } 1748 DESCRIPTION 1749 "Implementation of the 'cpu(12)' enumeration is not 1750 required." 1752 ::= { entityCompliances 2 } 1754 entity3Compliance MODULE-COMPLIANCE 1755 STATUS current 1756 DESCRIPTION 1757 "The compliance statement for SNMP entities which implement 1758 version 3 of the Entity MIB." 1759 MODULE -- this module 1760 MANDATORY-GROUPS { 1761 entityPhysicalGroup, 1762 entityPhysical2Group, 1763 entityGeneralGroup, 1764 entityNotificationsGroup 1765 } 1766 GROUP entityLogical2Group 1767 DESCRIPTION 1768 "Implementation of this group is not mandatory for agents 1769 which model all MIB object instances within a single naming 1770 scope." 1772 GROUP entityMappingGroupRev1 1773 DESCRIPTION 1774 "Implementation of the entPhysicalContainsTable is mandatory 1775 for all agents. Implementation of the entAliasMappingTable 1776 is not mandatory for agents which model all MIB object 1777 instances within a single naming scope. 1779 Note that the entAliasMappingTable may be useful for all 1780 agents, however implementation of the entityLogicalGroup or 1781 entityLogical2Group is required to support this table." 1783 OBJECT entPhysicalSerialNum 1784 MIN-ACCESS not-accessible 1785 DESCRIPTION 1786 "Read and write access is not required for agents which 1787 cannot identify serial number information for physical 1788 entities, and/or cannot provide non-volatile storage for 1789 NMS-assigned serial numbers. 1791 Write access is not required for agents which can identify 1792 serial number information for physical entities, but cannot 1793 provide non-volatile storage for NMS-assigned serial 1794 numbers. 1796 Write access is not required for physical entities for 1797 physical entities for which the associated value of the 1798 entPhysicalIsFRU object is equal to 'false(2)'." 1800 OBJECT entPhysicalAlias 1801 MIN-ACCESS read-only 1802 DESCRIPTION 1803 "Write access is required only if the associated 1804 entPhysicalClass value is equal to 'chassis(3)'." 1806 OBJECT entPhysicalAssetID 1807 MIN-ACCESS not-accessible 1808 DESCRIPTION 1809 "Read and write access is not required for agents which 1810 cannot provide non-volatile storage for NMS-assigned asset 1811 identifiers. 1813 Write access is not required for physical entities for which 1814 the associated value of entPhysicalIsFRU is equal to 1815 'false(2)'." 1816 ::= { entityCompliances 3 } 1818 -- MIB groupings 1819 entityPhysicalGroup OBJECT-GROUP 1820 OBJECTS { 1821 entPhysicalDescr, 1822 entPhysicalVendorType, 1823 entPhysicalContainedIn, 1824 entPhysicalClass, 1825 entPhysicalParentRelPos, 1826 entPhysicalName 1828 } 1829 STATUS current 1830 DESCRIPTION 1831 "The collection of objects which are used to represent 1832 physical system components, for which a single agent 1833 provides management information." 1834 ::= { entityGroups 1 } 1836 entityLogicalGroup OBJECT-GROUP 1837 OBJECTS { 1838 entLogicalDescr, 1839 entLogicalType, 1840 entLogicalCommunity, 1841 entLogicalTAddress, 1842 entLogicalTDomain 1843 } 1844 STATUS deprecated 1845 DESCRIPTION 1846 "The collection of objects which are used to represent the 1847 list of logical entities for which a single agent provides 1848 management information." 1849 ::= { entityGroups 2 } 1851 entityMappingGroup OBJECT-GROUP 1852 OBJECTS { 1853 entLPPhysicalIndex, 1854 entAliasMappingIdentifier, 1855 entPhysicalChildIndex 1856 } 1857 STATUS deprecated 1858 DESCRIPTION 1859 "The collection of objects which are used to represent the 1860 associations between multiple logical entities, physical 1861 components, interfaces, and port identifiers for which a 1862 single agent provides management information." 1863 ::= { entityGroups 3 } 1865 entityGeneralGroup OBJECT-GROUP 1866 OBJECTS { 1867 entLastChangeTime 1868 } 1869 STATUS current 1870 DESCRIPTION 1871 "The collection of objects which are used to represent 1872 general entity information for which a single agent provides 1873 management information." 1874 ::= { entityGroups 4 } 1876 entityNotificationsGroup NOTIFICATION-GROUP 1877 NOTIFICATIONS { entConfigChange } 1878 STATUS current 1879 DESCRIPTION 1880 "The collection of notifications used to indicate Entity MIB 1881 data consistency and general status information." 1882 ::= { entityGroups 5 } 1884 entityPhysical2Group OBJECT-GROUP 1885 OBJECTS { 1886 entPhysicalHardwareRev, 1887 entPhysicalFirmwareRev, 1888 entPhysicalSoftwareRev, 1889 entPhysicalSerialNum, 1890 entPhysicalMfgName, 1891 entPhysicalModelName, 1892 entPhysicalAlias, 1893 entPhysicalAssetID, 1894 entPhysicalIsFRU 1895 } 1896 STATUS current 1897 DESCRIPTION 1898 "The collection of objects which are used to represent 1899 physical system components, for which a single agent 1900 provides management information. This group augments the 1901 objects contained in the entityPhysicalGroup." 1902 ::= { entityGroups 6 } 1904 entityLogical2Group OBJECT-GROUP 1905 OBJECTS { 1906 entLogicalDescr, 1907 entLogicalType, 1908 entLogicalTAddress, 1909 entLogicalTDomain, 1910 entLogicalContextEngineID, 1911 entLogicalContextName 1912 } 1913 STATUS current 1914 DESCRIPTION 1915 "The collection of objects which are used to represent the 1916 list of logical entities for which a single SNMP entity 1917 provides management information." 1919 ::= { entityGroups 7 } 1921 entityMappingGroupRev1 OBJECT-GROUP 1922 OBJECTS { 1923 entAliasMappingIdentifier, 1924 entPhysicalChildIndex 1925 } 1926 STATUS current 1927 DESCRIPTION 1928 "The collection of objects which are used to represent the 1929 associations between multiple logical entities, physical 1930 components, interfaces, and port identifiers for which a 1931 single agent provides management information." 1932 ::= { entityGroups 8 } 1934 END 1935 6. Usage Examples 1937 The following sections iterate the instance values for two example 1938 networking devices. These examples are kept simple to make them more 1939 understandable. Auxiliary components, such as fans, sensors, empty 1940 slots, and sub-modules are not shown, but might be modeled in real 1941 implementations. 1943 6.1. Router/Bridge 1945 A router containing two slots. Each slot contains a 3 port 1946 router/bridge module. Each port is represented in the ifTable. There 1947 are two logical instances of OSPF running and two logical bridges: 1949 Physical entities -- entPhysicalTable: 1950 1 Field-replaceable physical chassis: 1951 entPhysicalDescr.1 == 'Acme Chassis Model 100' 1952 entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 1953 entPhysicalContainedIn.1 == 0 1954 entPhysicalClass.1 == chassis(3) 1955 entPhysicalParentRelPos.1 == 0 1956 entPhysicalName.1 == '100-A' 1957 entPhysicalHardwareRev.1 == 'A(1.00.02)' 1958 entPhysicalSoftwareRev.1 == '' 1959 entPhysicalFirmwareRev.1 == '' 1960 entPhysicalSerialNum.1 == 'C100076544' 1961 entPhysicalMfgName.1 == 'Acme' 1962 entPhysicalModelName.1 == '100' 1963 entPhysicalAlias.1 == 'cl-SJ17-3-006:rack1:rtr-U3' 1964 entPhysicalAssetID.1 == '0007372293' 1965 entPhysicalIsFRU.1 == true(1) 1967 2 slots within the chassis: 1968 entPhysicalDescr.2 == 'Acme Chassis Slot Type AA' 1969 entPhysicalVendorType.2 == acmeProducts.slotTypes.1 1970 entPhysicalContainedIn.2 == 1 1971 entPhysicalClass.2 == container(5) 1972 entPhysicalParentRelPos.2 == 1 1973 entPhysicalName.2 == 'S1' 1974 entPhysicalHardwareRev.2 == 'B(1.00.01)' 1975 entPhysicalSoftwareRev.2 == '' 1976 entPhysicalFirmwareRev.2 == '' 1977 entPhysicalSerialNum.2 == '' 1978 entPhysicalMfgName.2 == 'Acme' 1979 entPhysicalModelName.2 == 'AA' 1980 entPhysicalAlias.2 == '' 1981 entPhysicalAssetID.2 == '' 1982 entPhysicalIsFRU.2 == false(2) 1984 entPhysicalDescr.3 == 'Acme Chassis Slot Type AA' 1985 entPhysicalVendorType.3 = acmeProducts.slotTypes.1 1986 entPhysicalContainedIn.3 == 1 1987 entPhysicalClass.3 == container(5) 1988 entPhysicalParentRelPos.3 == 2 1989 entPhysicalName.3 == 'S2' 1990 entPhysicalHardwareRev.3 == '1.00.07' 1991 entPhysicalSoftwareRev.3 == '' 1992 entPhysicalFirmwareRev.3 == '' 1993 entPhysicalSerialNum.3 == '' 1994 entPhysicalMfgName.3 == 'Acme' 1995 entPhysicalModelName.3 == 'AA' 1996 entPhysicalAlias.3 == '' 1997 entPhysicalAssetID.3 == '' 1998 entPhysicalIsFRU.3 == false(2) 2000 2 Field-replaceable modules: 2001 Slot 1 contains a module with 3 ports: 2002 entPhysicalDescr.4 == 'Acme Router-100' 2003 entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 2004 entPhysicalContainedIn.4 == 2 2005 entPhysicalClass.4 == module(9) 2006 entPhysicalParentRelPos.4 == 1 2007 entPhysicalName.4 == 'M1' 2008 entPhysicalHardwareRev.4 == '1.00.07' 2009 entPhysicalSoftwareRev.4 == '1.4.1' 2010 entPhysicalFirmwareRev.4 == 'A(1.1)' 2011 entPhysicalSerialNum.4 == 'C100087363' 2012 entPhysicalMfgName.4 == 'Acme' 2013 entPhysicalModelName.4 == 'R100-FE' 2014 entPhysicalAlias.4 == 'rtr-U3:m1:SJ17-3-eng' 2015 entPhysicalAssetID.4 == '0007372462' 2016 entPhysicalIsFRU.4 == true(1) 2018 entPhysicalDescr.5 == 'Acme Ethernet-100 Port' 2019 entPhysicalVendorType.5 == acmeProducts.portTypes.2 2020 entPhysicalContainedIn.5 == 4 2021 entPhysicalClass.5 == port(10) 2022 entPhysicalParentRelPos.5 == 1 2023 entPhysicalName.5 == 'P1' 2024 entPhysicalHardwareRev.5 == 'G(1.02)' 2025 entPhysicalSoftwareRev.5 == '' 2026 entPhysicalFirmwareRev.5 == '1.1' 2027 entPhysicalSerialNum.5 == '' 2028 entPhysicalMfgName.5 == 'Acme' 2029 entPhysicalModelName.5 == 'FE-100' 2030 entPhysicalAlias.5 == '' 2031 entPhysicalAssetID.5 == '' 2032 entPhysicalIsFRU.5 == false(2) 2034 entPhysicalDescr.6 == 'Acme Ethernet-100 Port' 2035 entPhysicalVendorType.6 == acmeProducts.portTypes.2 2036 entPhysicalContainedIn.6 == 4 2037 entPhysicalClass.6 == port(10) 2038 entPhysicalParentRelPos.6 == 2 2039 entPhysicalName.6 == 'P2' 2040 entPhysicalHardwareRev.6 == 'G(1.02)' 2041 entPhysicalSoftwareRev.6 == '' 2042 entPhysicalFirmwareRev.6 == '1.1' 2043 entPhysicalSerialNum.6 == '' 2044 entPhysicalMfgName.6 == 'Acme' 2045 entPhysicalModelName.6 == 'FE-100' 2046 entPhysicalAlias.6 == '' 2047 entPhysicalAssetID.6 == '' 2048 entPhysicalIsFRU.6 == false(2) 2050 entPhysicalDescr.7 == 'Acme Router-100 FDDI-Port' 2051 entPhysicalVendorType.7 == acmeProducts.portTypes.3 2052 entPhysicalContainedIn.7 == 4 2053 entPhysicalClass.7 == port(10) 2054 entPhysicalParentRelPos.7 == 3 2055 entPhysicalName.7 == 'P3' 2056 entPhysicalHardwareRev.7 == 'B(1.03)' 2057 entPhysicalSoftwareRev.7 == '2.5.1' 2058 entPhysicalFirmwareRev.7 == '2.5F' 2059 entPhysicalSerialNum.7 == '' 2060 entPhysicalMfgName.7 == 'Acme' 2061 entPhysicalModelName.7 == 'FDDI-100' 2062 entPhysicalAlias.7 == '' 2063 entPhysicalAssetID.7 == '' 2064 entPhysicalIsFRU.7 == false(2) 2066 Slot 2 contains another 3-port module: 2067 entPhysicalDescr.8 == 'Acme Router-100 Comm Module' 2068 entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 2069 entPhysicalContainedIn.8 == 3 2070 entPhysicalClass.8 == module(9) 2071 entPhysicalParentRelPos.8 == 1 2072 entPhysicalName.8 == 'M2' 2073 entPhysicalHardwareRev.8 == '2.01.00' 2074 entPhysicalSoftwareRev.8 == '3.0.7' 2075 entPhysicalFirmwareRev.8 == 'A(1.2)' 2076 entPhysicalSerialNum.8 == 'C100098732' 2077 entPhysicalMfgName.8 == 'Acme' 2078 entPhysicalModelName.8 == 'C100' 2079 entPhysicalAlias.8 == 'rtr-U3:m2:SJ17-2-eng' 2080 entPhysicalAssetID.8 == '0007373982' 2081 entPhysicalIsFRU.8 == true(1) 2083 entPhysicalDescr.9 == 'Acme Fddi-100 Port' 2084 entPhysicalVendorType.9 == acmeProducts.portTypes.5 2085 entPhysicalContainedIn.9 == 8 2086 entPhysicalClass.9 == port(10) 2087 entPhysicalParentRelPos.9 == 1 2088 entPhysicalName.9 == 'FDDI Primary' 2089 entPhysicalHardwareRev.9 == 'CC(1.07)' 2090 entPhysicalSoftwareRev.9 == '2.0.34' 2091 entPhysicalFirmwareRev.9 == '1.1' 2092 entPhysicalSerialNum.9 == '' 2093 entPhysicalMfgName.9 == 'Acme' 2094 entPhysicalModelName.9 == 'FDDI-100' 2095 entPhysicalAlias.9 == '' 2096 entPhysicalAssetID.9 == '' 2097 entPhysicalIsFRU.9 == false(2) 2099 entPhysicalDescr.10 == 'Acme Ethernet-100 Port' 2100 entPhysicalVendorType.10 == acmeProducts.portTypes.2 2101 entPhysicalContainedIn.10 == 8 2102 entPhysicalClass.10 == port(10) 2103 entPhysicalParentRelPos.10 == 2 2104 entPhysicalName.10 == 'Ethernet A' 2105 entPhysicalHardwareRev.10 == 'G(1.04)' 2106 entPhysicalSoftwareRev.10 == '' 2107 entPhysicalFirmwareRev.10 == '1.3' 2108 entPhysicalSerialNum.10 == '' 2109 entPhysicalMfgName.10 == 'Acme' 2110 entPhysicalModelName.10 == 'FE-100' 2111 entPhysicalAlias.10 == '' 2112 entPhysicalAssetID.10 == '' 2113 entPhysicalIsFRU.10 == false(2) 2114 entPhysicalDescr.11 == 'Acme Ethernet-100 Port' 2115 entPhysicalVendorType.11 == acmeProducts.portTypes.2 2116 entPhysicalContainedIn.11 == 8 2117 entPhysicalClass.11 == port(10) 2118 entPhysicalParentRelPos.11 == 3 2119 entPhysicalName.11 == 'Ethernet B' 2120 entPhysicalHardwareRev.11 == 'G(1.04)' 2121 entPhysicalSoftwareRev.11 == '' 2122 entPhysicalFirmwareRev.11 == '1.3' 2123 entPhysicalSerialNum.11 == '' 2124 entPhysicalMfgName.11 == 'Acme' 2125 entPhysicalModelName.11 == 'FE-100' 2126 entPhysicalAlias.11 == '' 2127 entPhysicalAssetID.11 == '' 2128 entPhysicalIsFRU.11 == false(2) 2130 Logical entities -- entLogicalTable; no SNMPv3 support 2131 2 OSPF instances: 2132 entLogicalDescr.1 == 'Acme OSPF v1.1' 2133 entLogicalType.1 == ospf 2134 entLogicalCommunity.1 == 'public-ospf1' 2135 entLogicalTAddress.1 == 124.125.126.127:161 2136 entLogicalTDomain.1 == snmpUDPDomain 2137 entLogicalContextEngineID.1 == '' 2138 entLogicalContextName.1 == '' 2140 entLogicalDescr.2 == 'Acme OSPF v1.1' 2141 entLogicalType.2 == ospf 2142 entLogicalCommunity.2 == 'public-ospf2' 2143 entLogicalTAddress.2 == 124.125.126.127:161 2144 entLogicalTDomain.2 == snmpUDPDomain 2145 entLogicalContextEngineID.2 == '' 2146 entLogicalContextName.2 == '' 2148 2 logical bridges: 2149 entLogicalDescr.3 == 'Acme Bridge v2.1.1' 2150 entLogicalType.3 == dot1dBridge 2151 entLogicalCommunity.3 == 'public-bridge1' 2152 entLogicalTAddress.3 == 124.125.126.127:161 2153 entLogicalTDomain.3 == snmpUDPDomain 2154 entLogicalContextEngineID.3 == '' 2155 entLogicalContextName.3 == '' 2157 entLogicalDescr.4 == 'Acme Bridge v2.1.1' 2158 entLogicalType.4 == dot1dBridge 2159 entLogicalCommunity.4 == 'public-bridge2' 2160 entLogicalTAddress.4 == 124.125.126.127:161 2161 entLogicalTDomain.4 == snmpUDPDomain 2162 entLogicalContextEngineID.4 == '' 2163 entLogicalContextName.4 == '' 2165 Logical to Physical Mappings: 2166 1st OSPF instance: uses module 1-port 1 2167 entLPPhysicalIndex.1.5 == 5 2169 2nd OSPF instance: uses module 2-port 1 2170 entLPPhysicalIndex.2.9 == 9 2172 1st bridge group: uses module 1, all ports 2174 [ed. -- Note that these mappings are included in the table since 2175 another logical entity (1st OSPF) utilizes one of the 2176 ports. If this were not the case, then a single mapping 2177 to the module (e.g., entLPPhysicalIndex.3.4) would be 2178 present instead. ] 2179 entLPPhysicalIndex.3.5 == 5 2180 entLPPhysicalIndex.3.6 == 6 2181 entLPPhysicalIndex.3.7 == 7 2183 2nd bridge group: uses module 2, all ports 2184 entLPPhysicalIndex.4.9 == 9 2185 entLPPhysicalIndex.4.10 == 10 2186 entLPPhysicalIndex.4.11 == 11 2188 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 2189 Example 1: ifIndex values are global to all logical entities 2190 entAliasMappingIdentifier.5.0 == ifIndex.1 2191 entAliasMappingIdentifier.6.0 == ifIndex.2 2192 entAliasMappingIdentifier.7.0 == ifIndex.3 2193 entAliasMappingIdentifier.9.0 == ifIndex.4 2194 entAliasMappingIdentifier.10.0 == ifIndex.5 2195 entAliasMappingIdentifier.11.0 == ifIndex.6 2197 Example 2: ifIndex values are not shared by all logical entities 2198 entAliasMappingIdentifier.5.0 == ifIndex.1 2199 entAliasMappingIdentifier.5.3 == ifIndex.101 2200 entAliasMappingIdentifier.6.0 == ifIndex.2 2201 entAliasMappingIdentifier.6.3 == ifIndex.102 2202 entAliasMappingIdentifier.7.0 == ifIndex.3 2203 entAliasMappingIdentifier.7.3 == ifIndex.103 2204 entAliasMappingIdentifier.9.0 == ifIndex.4 2205 entAliasMappingIdentifier.9.3 == ifIndex.204 2206 entAliasMappingIdentifier.10.0 == ifIndex.5 2207 entAliasMappingIdentifier.10.3 == ifIndex.205 2208 entAliasMappingIdentifier.11.0 == ifIndex.6 2209 entAliasMappingIdentifier.11.3 == ifIndex.206 2211 Physical Containment Tree -- entPhysicalContainsTable 2212 chassis has two containers: 2213 entPhysicalChildIndex.1.2 == 2 2214 entPhysicalChildIndex.1.3 == 3 2216 container 1 has a module: 2217 entPhysicalChildIndex.2.4 == 4 2219 container 2 has a module: 2220 entPhysicalChildIndex.3.8 == 8 2222 module 1 has 3 ports: 2223 entPhysicalChildIndex.4.5 == 5 2224 entPhysicalChildIndex.4.6 == 6 2225 entPhysicalChildIndex.4.7 == 7 2227 module 2 has 3 ports: 2228 entPhysicalChildIndex.8.9 == 9 2229 entPhysicalChildIndex.8.10 == 10 2230 entPhysicalChildIndex.1.11 == 11 2232 6.2. Repeaters 2234 A 3-slot Hub with 2 backplane ethernet segments. Slot three is empty, 2235 and the remaining slots contain ethernet repeater modules. 2237 Note that this example assumes an older Repeater MIB implementation, 2238 (RFC 1516 [RFC1516]) rather than the new Repeater MIB (RFC 2108 2239 [RFC2108]). The new version contains an object called 'rptrPortRptrId', 2240 which should be used to identify repeater port groupings, rather than 2241 with community strings or contexts. 2243 Physical entities -- entPhysicalTable: 2244 1 Field-replaceable physical chassis: 2245 entPhysicalDescr.1 == 'Acme Chassis Model 110' 2246 entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 2247 entPhysicalContainedIn.1 == 0 2248 entPhysicalClass.1 == chassis(3) 2249 entPhysicalParentRelPos.1 == 0 2250 entPhysicalName.1 == '110-B' 2251 entPhysicalHardwareRev.1 == 'A(1.02.00)' 2252 entPhysicalSoftwareRev.1 == '' 2253 entPhysicalFirmwareRev.1 == '' 2254 entPhysicalSerialNum.1 == 'C100079294' 2255 entPhysicalMfgName.1 == 'Acme' 2256 entPhysicalModelName.1 == '110' 2257 entPhysicalAlias.1 == 'bldg09:floor1:rptr18:0067eea0229f' 2258 entPhysicalAssetID.1 == '0007386327' 2259 entPhysicalIsFRU.1 == true(1) 2261 2 Chassis Ethernet Backplanes: 2262 entPhysicalDescr.2 == 'Acme Ethernet Backplane Type A' 2263 entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 2264 entPhysicalContainedIn.2 == 1 2265 entPhysicalClass.2 == backplane(4) 2266 entPhysicalParentRelPos.2 == 1 2267 entPhysicalName.2 == 'B1' 2268 entPhysicalHardwareRev.2 == 'A(2.04.01)' 2269 entPhysicalSoftwareRev.2 == '' 2270 entPhysicalFirmwareRev.2 == '' 2271 entPhysicalSerialNum.2 == '' 2272 entPhysicalMfgName.2 == 'Acme' 2273 entPhysicalModelName.2 == 'BK-A' 2274 entPhysicalAlias.2 == '' 2275 entPhysicalAssetID.2 == '' 2276 entPhysicalIsFRU.2 == false(2) 2278 entPhysicalDescr.3 == 'Acme Ethernet Backplane Type A' 2279 entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 2280 entPhysicalContainedIn.3 == 1 2281 entPhysicalClass.3 == backplane(4) 2282 entPhysicalParentRelPos.3 == 2 2283 entPhysicalName.3 == 'B2' 2284 entPhysicalHardwareRev.3 == 'A(2.04.01)' 2285 entPhysicalSoftwareRev.3 == '' 2286 entPhysicalFirmwareRev.3 == '' 2287 entPhysicalSerialNum.3 == '' 2288 entPhysicalMfgName.3 == 'Acme' 2289 entPhysicalModelName.3 == 'BK-A' 2290 entPhysicalAlias.3 == '' 2291 entPhysicalAssetID.3 == '' 2292 entPhysicalIsFRU.3 == false(2) 2294 3 slots within the chassis: 2295 entPhysicalDescr.4 == 'Acme Hub Slot Type RB' 2296 entPhysicalVendorType.4 == acmeProducts.slotTypes.5 2297 entPhysicalContainedIn.4 == 1 2298 entPhysicalClass.4 == container(5) 2299 entPhysicalParentRelPos.4 == 1 2300 entPhysicalName.4 == 'Slot 1' 2301 entPhysicalHardwareRev.4 == 'B(1.00.03)' 2302 entPhysicalSoftwareRev.4 == '' 2303 entPhysicalFirmwareRev.4 == '' 2304 entPhysicalSerialNum.4 == '' 2305 entPhysicalMfgName.4 == 'Acme' 2306 entPhysicalModelName.4 == 'RB' 2307 entPhysicalAlias.4 == '' 2308 entPhysicalAssetID.4 == '' 2309 entPhysicalIsFRU.4 == false(2) 2311 entPhysicalDescr.5 == 'Acme Hub Slot Type RB' 2312 entPhysicalVendorType.5 == acmeProducts.slotTypes.5 2313 entPhysicalContainedIn.5 == 1 2314 entPhysicalClass.5 == container(5) 2315 entPhysicalParentRelPos.5 == 2 2316 entPhysicalName.5 == 'Slot 2' 2317 entPhysicalHardwareRev.5 == 'B(1.00.03)' 2318 entPhysicalSoftwareRev.5 == '' 2319 entPhysicalFirmwareRev.5 == '' 2320 entPhysicalSerialNum.5 == '' 2321 entPhysicalMfgName.5 == 'Acme' 2322 entPhysicalModelName.5 == 'RB' 2323 entPhysicalAlias.5 == '' 2324 entPhysicalAssetID.5 == '' 2325 entPhysicalIsFRU.5 == false(2) 2327 entPhysicalDescr.6 == 'Acme Hub Slot Type RB' 2328 entPhysicalVendorType.6 == acmeProducts.slotTypes.5 2329 entPhysicalContainedIn.6 == 1 2330 entPhysicalClass.6 == container(5) 2331 entPhysicalParentRelPos.6 == 3 2332 entPhysicalName.6 == 'Slot 3' 2333 entPhysicalHardwareRev.6 == 'B(1.00.03)' 2334 entPhysicalSoftwareRev.6 == '' 2335 entPhysicalFirmwareRev.6 == '' 2336 entPhysicalSerialNum.6 == '' 2337 entPhysicalMfgName.6 == 'Acme' 2338 entPhysicalModelName.6 == 'RB' 2339 entPhysicalAlias.6 == '' 2340 entPhysicalAssetID.6 == '' 2341 entPhysicalIsFRU.6 == false(2) 2343 Slot 1 contains a plug-in module with 4 10-BaseT ports: 2344 entPhysicalDescr.7 == 'Acme 10Base-T Module 114' 2345 entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 2346 entPhysicalContainedIn.7 == 4 2347 entPhysicalClass.7 == module(9) 2348 entPhysicalParentRelPos.7 == 1 2349 entPhysicalName.7 == 'M1' 2350 entPhysicalHardwareRev.7 == 'A(1.02.01)' 2351 entPhysicalSoftwareRev.7 == '1.7.2' 2352 entPhysicalFirmwareRev.7 == 'A(1.5)' 2353 entPhysicalSerialNum.7 == 'C100096244' 2354 entPhysicalMfgName.7 == 'Acme' 2355 entPhysicalModelName.7 = '114' 2356 entPhysicalAlias.7 == 'bldg09:floor1:eng' 2357 entPhysicalAssetID.7 == '0007962951' 2358 entPhysicalIsFRU.7 == true(1) 2360 entPhysicalDescr.8 == 'Acme 10Base-T Port RB' 2361 entPhysicalVendorType.8 == acmeProducts.portTypes.10 2362 entPhysicalContainedIn.8 == 7 2363 entPhysicalClass.8 == port(10) 2364 entPhysicalParentRelPos.8 == 1 2365 entPhysicalName.8 == 'Ethernet-A' 2366 entPhysicalHardwareRev.8 == 'A(1.04F)' 2367 entPhysicalSoftwareRev.8 == '' 2368 entPhysicalFirmwareRev.8 == '1.4' 2369 entPhysicalSerialNum.8 == '' 2370 entPhysicalMfgName.8 == 'Acme' 2371 entPhysicalModelName.8 == 'RB' 2372 entPhysicalAlias.8 == '' 2373 entPhysicalAssetID.8 == '' 2374 entPhysicalIsFRU.8 == false(2) 2376 entPhysicalDescr.9 == 'Acme 10Base-T Port RB' 2377 entPhysicalVendorType.9 == acmeProducts.portTypes.10 2378 entPhysicalContainedIn.9 == 7 2379 entPhysicalClass.9 == port(10) 2380 entPhysicalParentRelPos.9 == 2 2381 entPhysicalName.9 == 'Ethernet-B' 2382 entPhysicalHardwareRev.9 == 'A(1.04F)' 2383 entPhysicalSoftwareRev.9 == '' 2384 entPhysicalFirmwareRev.9 == '1.4' 2385 entPhysicalSerialNum.9 == '' 2386 entPhysicalMfgName.9 == 'Acme' 2387 entPhysicalModelName.9 = 'RB' 2388 entPhysicalAlias.9 == '' 2389 entPhysicalAssetID.9 == '' 2390 entPhysicalIsFRU.9 == false(2) 2392 entPhysicalDescr.10 == 'Acme 10Base-T Port RB' 2393 entPhysicalVendorType.10 == acmeProducts.portTypes.10 2394 entPhysicalContainedIn.10 == 7 2395 entPhysicalClass.10 == port(10) 2396 entPhysicalParentRelPos.10 == 3 2397 entPhysicalName.10 == 'Ethernet-C' 2398 entPhysicalHardwareRev.10 == 'B(1.02.07)' 2399 entPhysicalSoftwareRev.10 == '' 2400 entPhysicalFirmwareRev.10 == '1.4' 2401 entPhysicalSerialNum.10 == '' 2402 entPhysicalMfgName.10 == 'Acme' 2403 entPhysicalModelName.10 == 'RB' 2404 entPhysicalAlias.10 == '' 2405 entPhysicalAssetID.10 == '' 2406 entPhysicalIsFRU.10 == false(2) 2408 entPhysicalDescr.11 == 'Acme 10Base-T Port RB' 2409 entPhysicalVendorType.11 == acmeProducts.portTypes.10 2410 entPhysicalContainedIn.11 == 7 2411 entPhysicalClass.11 == port(10) 2412 entPhysicalParentRelPos.11 == 4 2413 entPhysicalName.11 == 'Ethernet-D' 2414 entPhysicalHardwareRev.11 == 'B(1.02.07)' 2415 entPhysicalSoftwareRev.11 == '' 2416 entPhysicalFirmwareRev.11 == '1.4' 2417 entPhysicalSerialNum.11 == '' 2418 entPhysicalMfgName.11 == 'Acme' 2419 entPhysicalModelName.11 == 'RB' 2420 entPhysicalAlias.11 == '' 2421 entPhysicalAssetID.11 == '' 2422 entPhysicalIsFRU.11 == false(2) 2424 Slot 2 contains another ethernet module with 2 ports. 2425 entPhysicalDescr.12 == 'Acme 10Base-T Module Model 4' 2426 entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 2427 entPhysicalContainedIn.12 = 5 2428 entPhysicalClass.12 == module(9) 2429 entPhysicalParentRelPos.12 == 1 2430 entPhysicalName.12 == 'M2' 2431 entPhysicalHardwareRev.12 == 'A(1.01.07)' 2432 entPhysicalSoftwareRev.12 == '1.8.4' 2433 entPhysicalFirmwareRev.12 == 'A(1.8)' 2434 entPhysicalSerialNum.12 == 'C100102384' 2435 entPhysicalMfgName.12 == 'Acme' 2436 entPhysicalModelName.12 == '4' 2437 entPhysicalAlias.12 == 'bldg09:floor1:devtest' 2438 entPhysicalAssetID.12 == '0007968462' 2439 entPhysicalIsFRU.12 == true(1) 2441 entPhysicalDescr.13 == 'Acme 802.3 AUI Port' 2442 entPhysicalVendorType.13 == acmeProducts.portTypes.11 2443 entPhysicalContainedIn.13 == 12 2444 entPhysicalClass.13 == port(10) 2445 entPhysicalParentRelPos.13 == 1 2446 entPhysicalName.13 == 'AUI' 2447 entPhysicalHardwareRev.13 == 'A(1.06F)' 2448 entPhysicalSoftwareRev.13 == '' 2449 entPhysicalFirmwareRev.13 == '1.5' 2450 entPhysicalSerialNum.13 == '' 2451 entPhysicalMfgName.13 == 'Acme' 2452 entPhysicalModelName.13 == '' 2453 entPhysicalAlias.13 == '' 2454 entPhysicalAssetID.13 == '' 2455 entPhysicalIsFRU.13 == false(2) 2457 entPhysicalDescr.14 == 'Acme 10Base-T Port RD' 2458 entPhysicalVendorType.14 == acmeProducts.portTypes.14 2459 entPhysicalContainedIn.14 == 12 2460 entPhysicalClass.14 == port(10) 2461 entPhysicalParentRelPos.14 == 2 2462 entPhysicalName.14 == 'E2' 2463 entPhysicalHardwareRev.14 == 'B(1.01.02)' 2464 entPhysicalSoftwareRev.14 == '' 2465 entPhysicalFirmwareRev.14 == '2.1' 2466 entPhysicalSerialNum.14 == '' 2467 entPhysicalMfgName.14 == 'Acme' 2468 entPhysicalModelName.14 == '' 2469 entPhysicalAlias.14 == '' 2470 entPhysicalAssetID.14 == '' 2471 entPhysicalIsFRU.14 == false(2) 2473 Logical entities -- entLogicalTable; with SNMPv3 support 2474 Repeater 1--comprised of any ports attached to backplane 1 2475 entLogicalDescr.1 == 'Acme repeater v3.1' 2476 entLogicalType.1 == snmpDot3RptrMgt 2477 entLogicalCommunity.1 'public-repeater1' 2478 entLogicalTAddress.1 == 124.125.126.127:161 2479 entLogicalTDomain.1 == snmpUDPDomain 2480 entLogicalContextEngineID.1 == '80000777017c7d7e7f'H 2481 entLogicalContextName.1 == 'repeater1' 2483 Repeater 2--comprised of any ports attached to backplane 2: 2484 entLogicalDescr.2 == 'Acme repeater v3.1' 2485 entLogicalType.2 == snmpDot3RptrMgt 2486 entLogicalCommunity.2 == 'public-repeater2' 2487 entLogicalTAddress.2 == 124.125.126.127:161 2488 entLogicalTDomain.2 == snmpUDPDomain 2489 entLogicalContextEngineID.2 == '80000777017c7d7e7f'H 2490 entLogicalContextName.2 == 'repeater2' 2492 Logical to Physical Mappings -- entLPMappingTable: 2494 repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 2495 [ed. -- Note that a mapping to the module is not included, 2496 since in this example represents a port-switchable hub. 2497 Even though all ports on the module could belong to the 2498 same repeater as a matter of configuration, the LP port 2499 mappings should not be replaced dynamically with a single 2500 mapping for the module (e.g., entLPPhysicalIndex.1.7). 2501 If all ports on the module shared a single backplane connection, 2502 then a single mapping for the module would be more appropriate. ] 2504 entLPPhysicalIndex.1.2 == 2 2505 entLPPhysicalIndex.1.8 == 8 2506 entLPPhysicalIndex.1.9 == 9 2507 entLPPhysicalIndex.1.13 == 13 2509 repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 2510 entLPPhysicalIndex.2.3 == 3 2511 entLPPhysicalIndex.2.10 == 10 2512 entLPPhysicalIndex.2.11 == 11 2513 entLPPhysicalIndex.2.14 == 14 2515 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 2516 Repeater Port Identifier values are shared by both repeaters: 2517 entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1 2518 entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2 2519 entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3 2520 entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4 2521 entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1 2522 entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2 2524 Physical Containment Tree -- entPhysicalContainsTable 2525 chassis has two backplanes and three containers: 2526 entPhysicalChildIndex.1.2 == 2 2527 entPhysicalChildIndex.1.3 == 3 2528 entPhysicalChildIndex.1.4 == 4 2529 entPhysicalChildIndex.1.5 == 5 2530 entPhysicalChildIndex.1.6 == 6 2532 container 1 has a module: 2533 entPhysicalChildIndex.4.7 == 7 2535 container 2 has a module 2536 entPhysicalChildIndex.5.12 == 12 2537 [ed. - in this example, container 3 is empty.] 2539 module 1 has 4 ports: 2540 entPhysicalChildIndex.7.8 == 8 2541 entPhysicalChildIndex.7.9 == 9 2542 entPhysicalChildIndex.7.10 == 10 2543 entPhysicalChildIndex.7.11 == 11 2545 module 2 has 2 ports: 2546 entPhysicalChildIndex.12.13 == 13 2547 entPhysicalChildIndex.12.14 == 14 2549 7. Intellectual Property 2551 The IETF takes no position regarding the validity or scope of any 2552 intellectual property or other rights that might be claimed to pertain 2553 to the implementation or use of the technology described in this 2554 document or the extent to which any license under such rights might or 2555 might not be available; neither does it represent that it has made any 2556 effort to identify any such rights. Information on the IETF's 2557 procedures with respect to rights in standards-track and standards- 2558 related documentation can be found in BCP-11. Copies of claims of 2559 rights made available for publication and any assurances of licenses to 2560 be made available, or the result of an attempt made to obtain a general 2561 license or permission for the use of such proprietary rights by 2562 implementors or users of this specification can be obtained from the 2563 IETF Secretariat. 2565 The IETF invites any interested party to bring to its attention any 2566 copyrights, patents or patent applications, or other proprietary rights 2567 which may cover technology that may be required to practice this 2568 standard. Please address the information to the IETF Executive 2569 Director. 2571 8. Acknowledgements 2573 This memo has been produced by the IETF's Entity MIB working group. 2575 9. Normative References 2577 [RFC2026] 2578 Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2579 2026, October, 1996. 2581 [RFC2578] 2582 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2583 and S. Waldbusser, "Structure of Management Information Version 2 2584 (SMIv2)", STD 58, RFC 2578, April 1999. 2586 [RFC2579] 2587 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2588 and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2589 2579, April 1999. 2591 [RFC2580] 2592 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2593 and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2594 2580, April 1999. 2596 [RFC3411] 2597 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 2598 Describing Simple Network Management Protocol (SNMP) Management 2599 Frameworks", STD 62, RFC 3411, December 2002. 2601 [RFC3417] 2602 R. Presuhn, Ed., "Transport Mappings for the Simple Network 2603 Management Protocol (SNMP)", STD 62, RFC 3417, December 2002. 2605 10. Informative References 2607 [RFC1157] 2608 Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 2609 Management Protocol", STD 15, RFC 1157, May 1990. 2611 [RFC1493] 2612 Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, 2613 "Definitions of Managed Objects for Bridges", RFC 1493, July, 1993. 2615 [RFC1516] 2616 McMaster, D., and K. McCloghrie, "Definitions of Managed Objects 2617 for IEEE 802.3 Repeater Devices", RFC 1516, September, 1993. 2619 [RFC2037] 2620 McCloghrie, K., and A. Bierman, "Entity MIB using SMIv2", RFC 2037, 2621 October 1996. 2623 [RFC2108] 2624 de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, 2625 "Definitions of Managed Objects for IEEE 802.3 Repeater Devices 2626 using SMIv2", RFC 2108, February, 1997. 2628 [RFC2863] 2629 McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC 2630 2863, June, 2000. 2632 [RFC2737] 2633 McCloghrie, K., and A. Bierman, "Entity MIB (Version 2)", RFC 2737, 2634 December 1999. 2636 [RFC3410] 2637 Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and 2638 Applicability Statements for Internet- Standard Management 2639 Framework", RFC 3410, December 2002. 2641 11. Security Considerations 2643 There are a number of management objects defined in this MIB that have a 2644 MAX-ACCESS clause of read-write and/or read-create. Such objects may be 2645 considered sensitive or vulnerable in some network environments. The 2646 support for SET operations in a non-secure environment without proper 2647 protection can have a negative effect on network operations. 2649 There are a number of managed objects in this MIB that may contain 2650 sensitive information. These are: 2652 entPhysicalDescr 2653 entPhysicalVendorType 2654 entPhysicalHardwareRev 2655 entPhysicalFirmwareRev 2656 entPhysicalSoftwareRev 2657 entPhysicalSerialNum 2658 entPhysicalMfgName 2659 entPhysicalModelName 2661 These objects expose information about the physical entities within a 2662 managed system, which may be used to identify the vendor, model, and 2663 version information of each system component. 2665 entPhysicalAssetID 2667 This object can allow asset identifiers for various system components to 2668 be exposed, in the event this MIB object is actually configured by an 2669 NMS application. 2671 entLogicalDescr 2672 entLogicalType 2674 These objects expose the type of logical entities present in the managed 2675 system. 2677 entLogicalCommunity 2679 This object exposes community names associated with particular logical 2680 entities within the system. 2682 entLogicalTAddress 2683 entLogicalTDomain 2685 These objects expose network addresses that can be used to communicate 2686 with an SNMP agent on behalf of particular logical entities within the 2687 system. 2689 entLogicalContextEngineID 2690 entLogicalContextName 2692 These objects identify the authoritative SNMP engine that contains 2693 information on behalf of particular logical entities within the system. 2695 It is thus important to control even GET access to these objects and 2696 possibly to even encrypt the values of these object when sending them 2697 over the network via SNMP. Not all versions of SNMP provide features 2698 for such a secure environment. 2700 SNMPv1 by itself is not a secure environment. Even if the network 2701 itself is secure (for example by using IPSec), even then, there is no 2702 control as to who on the secure network is allowed to access and GET/SET 2703 (read/change/create/delete) the objects in this MIB. 2705 It is recommended that the implementers consider the security features 2706 as provided by the SNMPv3 framework. Specifically, the use of the User- 2707 based Security Model RFC 2574 [RFC2574] and the View-based Access 2708 Control Model RFC 2575 [RFC2575] is recommended. 2710 It is then a customer/user responsibility to ensure that the SNMP entity 2711 giving access to an instance of this MIB, is properly configured to give 2712 access to the objects only to those principals (users) that have 2713 legitimate rights to indeed GET or SET (change/create/delete) them. 2715 12. Authors' Addresses 2717 Andy Bierman 2718 Cisco Systems, Inc. 2719 170 West Tasman Drive 2720 San Jose, CA 95134 USA 2721 Phone: +1 408-527-3711 2722 Email: abierman@cisco.com 2724 Keith McCloghrie 2725 Cisco Systems, Inc. 2726 170 West Tasman Drive 2727 San Jose, CA 95134 USA 2728 Phone: +1 408-526-5260 2729 Email: kzm@cisco.com 2731 13. Full Copyright Statement 2733 Copyright (C) The Internet Society (2003). All Rights Reserved. 2735 This document and translations of it may be copied and furnished to 2736 others, and derivative works that comment on or otherwise explain it or 2737 assist in its implementation may be prepared, copied, published and 2738 distributed, in whole or in part, without restriction of any kind, 2739 provided that the above copyright notice and this paragraph are included 2740 on all such copies and derivative works. However, this document itself 2741 may not be modified in any way, such as by removing the copyright notice 2742 or references to the Internet Society or other Internet organizations, 2743 except as needed for the purpose of developing Internet standards in 2744 which case the procedures for copyrights defined in the Internet 2745 Standards process must be followed, or as required to translate it into 2746 languages other than English. 2748 The limited permissions granted above are perpetual and will not be 2749 revoked by the Internet Society or its successors or assigns. 2751 This document and the information contained herein is provided on an "AS 2752 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2753 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2754 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2755 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2756 FITNESS FOR A PARTICULAR PURPOSE.