idnits 2.17.1 draft-ietf-entmib-v2-06.txt: ** The Abstract section seems to be numbered 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 88 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 65 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == 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 2500 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 (22 August 1999) is 9014 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) ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Obsolete normative reference: RFC 1493 (Obsoleted by RFC 4188) ** Obsolete normative reference: RFC 1516 (Obsoleted by RFC 2108) ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2037 (Obsoleted by RFC 2737) ** Obsolete normative reference: RFC 2233 (Obsoleted by RFC 2863) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) Summary: 21 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Entity MIB Working Group Keith McCloghrie 2 Internet Draft Cisco Systems, Inc. 3 Andy Bierman 4 Cisco Systems, Inc. 5 22 August 1999 7 Entity MIB (Version 2) 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 (1999). All Rights Reserved. 38 2. Abstract 40 This memo defines a portion of the Management Information Base (MIB) for 41 use with network management protocols in the Internet community. In 42 particular, it describes managed objects used for managing multiple 43 logical and physical entities managed by a single SNMP agent. 45 3. Table of Contents 47 1 Copyright Notice ................................................ 1 48 2 Abstract ........................................................ 2 49 3 Table of Contents ............................................... 2 50 4 The SNMP Management Framework ................................... 3 51 5 Overview ........................................................ 4 52 5.1 Terms ......................................................... 5 53 5.2 Relationship to Community Strings ............................. 6 54 5.3 Relationship to SNMP Contexts ................................. 6 55 5.4 Relationship to Proxy Mechanisms .............................. 7 56 5.5 Relationship to a Chassis MIB ................................. 7 57 5.6 Relationship to the Interfaces MIB ............................ 7 58 5.7 Relationship to the Other MIBs ................................ 8 59 5.8 Relationship to Naming Scopes ................................. 8 60 5.9 Multiple Instances of the Entity MIB .......................... 8 61 5.10 Re-Configuration of Entities ................................. 9 62 5.11 Textual Convention Change .................................... 9 63 5.12 MIB Structure ................................................ 10 64 5.12.1 entityPhysical Group ....................................... 10 65 5.12.2 entityLogical Group ........................................ 11 66 5.12.3 entityMapping Group ........................................ 11 67 5.12.4 entityGeneral Group ........................................ 12 68 5.12.5 entityNotifications Group .................................. 12 69 5.13 Multiple Agents .............................................. 12 70 5.14 Change Log ................................................... 13 71 5.14.1 Version 00 ................................................. 13 72 5.14.2 Version 01 ................................................. 14 73 5.14.3 Version 02 ................................................. 14 74 5.14.4 Version 03 ................................................. 14 75 5.14.5 Version 04 ................................................. 15 76 5.14.6 Version 05 ................................................. 15 77 5.14.7 Version 06 ................................................. 15 78 6 Definitions ..................................................... 16 79 7 Usage Examples .................................................. 44 80 7.1 Router/Bridge ................................................. 44 81 7.2 Repeaters ..................................................... 50 82 8 Intellectual Property ........................................... 58 83 9 Acknowledgements ................................................ 58 84 10 References ..................................................... 58 85 11 Security Considerations ........................................ 62 86 12 Authors' Addresses ............................................. 64 87 13 Full Copyright Statement ....................................... 65 89 4. The SNMP Management Framework 91 The SNMP Management Framework presently consists of five major 92 components: 94 o An overall architecture, described in RFC 2571 [RFC2571]. 96 o Mechanisms for describing and naming objects and events for the 97 purpose of management. The first version of this Structure of 98 Management Information (SMI) is called SMIv1 and described in 99 RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. 100 The second version, called SMIv2, is described in RFC 2578 101 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. 103 o Message protocols for transferring management information. The 104 first version of the SNMP message protocol is called SNMPv1 and 105 described in RFC 1157 [RFC1157]. A second version of the SNMP 106 message protocol, which is not an Internet standards track 107 protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] 108 and RFC 1906 [RFC1906]. The third version of the message 109 protocol is called SNMPv3 and described in RFC 1906 [RFC1906], 110 RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 112 o Protocol operations for accessing management information. The 113 first set of protocol operations and associated PDU formats is 114 described in RFC 1157 [RFC1157]. A second set of protocol 115 operations and associated PDU formats is described in RFC 1905 116 [RFC1905]. 118 o A set of fundamental applications described in RFC 2573 119 [RFC2573] and the view-based access control mechanism described 120 in RFC 2575 [RFC2575]. 122 A more detailed introduction to the current SNMP Management Framework 123 can be found in RFC 2570 [RFC2570]. 125 Managed objects are accessed via a virtual information store, termed 126 the Management Information Base or MIB. Objects in the MIB are 127 defined using the mechanisms defined in the SMI. 129 This memo specifies a MIB module that is compliant to the SMIv2. A 130 MIB conforming to the SMIv1 can be produced through the appropriate 131 translations. The resulting translated MIB must be semantically 132 equivalent, except where objects or events are omitted because no 133 translation is possible (use of Counter64). Some machine readable 134 information in SMIv2 will be converted into textual descriptions in 135 SMIv1 during the translation process. However, this loss of machine 136 readable information is not considered to change the semantics of the 137 MIB. 139 5. Overview 141 There is a need for a standardized way of representing a single agent 142 which supports multiple instances of one MIB. This is presently true 143 for at least 3 standard MIBs, and is likely to become true for more and 144 more MIBs as time passes. For example: 146 - multiple instances of a bridge supported within a single device 147 having a single agent; 149 - multiple repeaters supported by a single agent; 151 - multiple OSPF backbone areas, each one operating as part of its own 152 Autonomous System, and each identified by the same area-id (e.g., 153 0.0.0.0), supported inside a single router with one agent. 155 The fact that it is a single agent in each of these cases implies there 156 is some relationship which binds all of these entities together. 157 Effectively, there is some "overall" physical entity which houses the 158 sum of the things managed by that one agent, i.e., there are multiple 159 "logical" entities within a single physical entity. Sometimes, the 160 overall physical entity contains multiple (smaller) physical entities 161 and each logical entity is associated with a particular physical entity. 162 Sometimes, the overall physical entity is a "compound" of multiple 163 physical entities (e.g., a stack of stackable hubs). 165 What is needed is a way to determine exactly what logical entities are 166 managed by the agent (with some version of SNMP), and thereby to be able 167 to communicate with the agent about a particular logical entity. When 168 different logical entities are associated with different physical 169 entities within the overall physical entity, it is also useful to be 170 able to use this information to distinguish between logical entities. 172 In these situations, there is no need for varbinds for multiple logical 173 entities to be referenced in the same SNMP message (although that might 174 be useful in the future). Rather, it is sufficient, and in some 175 situations preferable, to have the context/community in the message 176 identify the logical entity to which the varbinds apply. 178 Version 2 of this MIB addresses new requirements that have emerged since 179 the publication of the first Entity MIB (RFC 2037 [RFC2037]). There is 180 a need for a standardized way of providing non-volatile, 181 administratively assigned identifiers for physical components 182 represented with the Entity MIB. There is also a need to align the 183 Entity MIB with the SNMPv3 administrative framework (RFC 2571 184 [RFC2571]). Implementation experience has shown that additional physical 185 component attributes are also desirable. 187 5.1. Terms 189 Some new terms are used throughout this document: 191 - Naming Scope 192 A "naming scope" represents the set of information that may be 193 potentially accessed through a single SNMP operation. All instances 194 within the naming scope share the same unique identifier space. 195 For SNMPv1, a naming scope is identified by the value of the 196 associated 'entLogicalCommunity' instance. For SNMPv3, the term 197 'context' is used instead of 'naming scope'. The complete 198 definition of an SNMP context can be found in section 3.3.1 of RFC 199 2571 [RFC2571]. 201 - Multi-Scoped Object 202 A MIB object, for which identical instance values identify 203 different managed information in different naming scopes, is called 204 a "multi-scoped" MIB object. 206 - Single-Scoped Object 207 A MIB object, for which identical instance values identify the same 208 managed information in different naming scopes, is called a 209 "single-scoped" MIB object. 211 - Logical Entity 212 A managed system contains one or more logical entities, each 213 represented by at most one instantiation of each of a particular 214 set of MIB objects. A set of management functions is associated 215 with each logical entity. Examples of logical entities include 216 routers, bridges, print-servers, etc. 218 - Physical Entity 219 A "physical entity" or "physical component" represents an 220 identifiable physical resource within a managed system. Zero or 221 more logical entities may utilize a physical resource at any given 222 time. It is an implementation-specific manner as to which physical 223 components are represented by an agent in the EntPhysicalTable. 224 Typically, physical resources (e.g., communications ports, 225 backplanes, sensors, daughter-cards, power supplies, the overall 226 chassis) which can be managed via functions associated with one or 227 more logical entities are included in the MIB. 229 - Containment Tree 230 Each physical component may be modeled as 'contained' within 231 another physical component. A "containment-tree" is the conceptual 232 sequence of entPhysicalIndex values which uniquely specifies the 233 exact physical location of a physical component within the managed 234 system. It is generated by 'following and recording' each 235 'entPhysicalContainedIn' instance 'up the tree towards the root', 236 until a value of zero indicating no further containment is found. 238 5.2. Relationship to Community Strings 240 For community-based SNMP, distinguishing between different logical 241 entities is one (but not the only) purpose of the community string (RFC 242 1157 [RFC1157]). This is accommodated by representing each community 243 string as a logical entity. 245 Note that different logical entities may share the same naming scope 246 (and therefore the same values of entLogicalCommunity). This is 247 possible, providing they have no need for the same instance of a MIB 248 object to represent different managed information. 250 5.3. Relationship to SNMP Contexts 252 Version 2 of the Entity MIB contains support for associating SNMPv3 253 contexts with logical entities. Two new MIB objects, defining an 254 SnmpEngineID and ContextName pair, are used together to identify an SNMP 255 context associated with a logical entity. This context can be used (in 256 conjunction with the entLogicalTAddress and entLogicalTDomain MIB 257 objects) to send SNMPv3 messages on behalf of a particular logical 258 entity. 260 5.4. Relationship to Proxy Mechanisms 262 The Entity MIB is designed to allow functional component discovery. The 263 administrative relationships between different logical entities are not 264 visible in any Entity MIB tables. An NMS cannot determine whether MIB 265 instances in different naming scopes are realized locally or remotely 266 (e.g., via some proxy mechanism) by examining any particular Entity MIB 267 objects. 269 The management of administrative framework functions is not an explicit 270 goal of the Entity MIB WG at this time. This new area of functionality 271 may be revisited after some operational experience with the Entity MIB 272 is gained. 274 Note that for community-based versions of SNMP, a network administrator 275 will likely be able to associate community strings with naming scopes 276 with proprietary mechanisms, as a matter of configuration. There are no 277 mechanisms for managing naming scopes defined in this MIB. 279 5.5. Relationship to a Chassis MIB 281 Some readers may recall that a previous IETF working group attempted to 282 define a Chassis MIB. No consensus was reached by that working group, 283 possibly because its scope was too broad. As such, it is not the 284 purpose of this MIB to be a "Chassis MIB replacement", nor is it within 285 the scope of this MIB to contain all the information which might be 286 necessary to manage a "chassis". On the other hand, the entities 287 represented by an implementation of this MIB might well be contained in 288 a chassis. 290 5.6. Relationship to the Interfaces MIB 292 The Entity MIB contains a mapping table identifying physical components 293 that have 'external values' (e.g., ifIndex) associated with them within 294 a given naming scope. This table can be used to identify the physical 295 location of each interface in the ifTable (RFC 2233 [RFC2233]). Since 296 ifIndex values in different contexts are not related to one another, the 297 interface to physical component associations are relative to the same 298 logical entity within the agent. 300 The Entity MIB also contains 'entPhysicalName' and 'entPhysicalAlias' 301 objects, which approximate the semantics of the 'ifName' and 'ifAlias' 302 objects (respectively) from the Interfaces MIB [RFC2233], for all types 303 of physical components. 305 5.7. Relationship to the Other MIBs 307 The Entity MIB contains a mapping table identifying physical components 308 that have identifiers from other standard MIBs associated with them. 309 For example, this table can be used along with the physical mapping 310 table to identify the physical location of each repeater port in the 311 rptrPortTable, or each interface in the ifTable. 313 5.8. Relationship to Naming Scopes 315 There is some question as to which MIB objects may be returned within a 316 given naming scope. MIB objects which are not multi-scoped within a 317 managed system are likely to ignore context information in 318 implementation. In such a case, it is likely such objects will be 319 returned in all naming scopes (e.g., not just the 'default' naming scope 320 or the SNMPv3 default context). 322 For example, a community string used to access the management 323 information for logical device 'bridge2' may allow access to all the 324 non-bridge related objects in the 'default' naming scope, as well as a 325 second instance of the Bridge MIB (RFC 1493 [RFC1493]). 327 It is an implementation-specific matter as to the isolation of single- 328 scoped MIB objects by the agent. An agent may wish to limit the objects 329 returned in a particular naming scope to just the multi-scoped objects 330 in that naming scope (e.g., system group and the Bridge MIB). In this 331 case, all single-scoped management information would belong to a common 332 naming scope (e.g., 'default'), which itself may contain some multi- 333 scoped objects (e.g., system group). 335 5.9. Multiple Instances of the Entity MIB 337 It is possible that more than one agent exists in a managed system, and 338 in such cases, multiple instances of the Entity MIB (representing the 339 same managed objects) may be available to an NMS. 341 In order to reduce complexity for agent implementation, multiple 342 instances of the Entity MIB are not required to be equivalent or even 343 consistent. An NMS may be able to 'align' instances returned by 344 different agents by examining the columns of each table, but vendor- 345 specific identifiers and (especially) index values are likely to be 346 different. Each agent may be managing different subsets of the entire 347 chassis as well. 349 When all of a physically-modular device is represented by a single 350 agent, the entry for which entPhysicalContainedIn has the value zero 351 would likely have 'chassis' as the value of its entPhysicalClass; 352 alternatively, for an agent on a module where the agent represents only 353 the physical entities on that module (not those on other modules), the 354 entry for which entPhysicalContainedIn has the value zero would likely 355 have 'module' as the value of its entPhysicalClass. 357 An agent implementation of the entLogicalTable is not required to 358 contain information about logical entities managed primarily by other 359 agents. That is, the entLogicalTAddress and entLogicalTDomain objects in 360 the entLogicalTable are provided to support an historical multiplexing 361 mechanism, not to identify other SNMP agents. 363 Note that the Entity MIB is a single-scoped MIB, in the event an agent 364 represents the MIB in different naming scopes. 366 5.10. Re-Configuration of Entities 368 Most of the MIB objects defined in this MIB have at most a read-only 369 MAX-ACCESS clause. This is a conscious decision by the working group to 370 limit this MIB's scope. The second version of the Entity MIB allows a 371 network administrator to configure some common attributes of physical 372 components. 374 5.11. Textual Convention Change 376 Version 1 of the Entity MIB contains three MIB objects defined with the 377 (now obsolete) DisplayString textual convention. In version 2 of the 378 Entity MIB, the syntax for these objects has been updated to use the 379 (now preferred) SnmpAdminString textual convention. 381 The working group realizes that this change is not strictly supported by 382 SMIv2. In our judgment, the alternative of deprecating the old objects 383 and defining new objects would have a more adverse impact on backward 384 compatibility and interoperability, given the particular semantics of 385 these objects. 387 5.12. MIB Structure 389 The Entity MIB contains five groups of MIB objects: 391 - entityPhysical group 392 Describes the physical entities managed by a single agent. 394 - entityLogical group 395 Describes the logical entities managed by a single agent. 397 - entityMapping group 398 Describes the associations between the physical entities, logical 399 entities, interfaces, and non-interface ports managed by a single 400 agent. 402 - entityGeneral group 403 Describes general system attributes shared by potentially all types 404 of entities managed by a single agent. 406 - entityNotifications group 407 Contains status indication notifications. 409 5.12.1. entityPhysical Group 411 This group contains a single table to identify physical system 412 components, called the entPhysicalTable. 414 The entPhysicalTable contains one row per physical entity, and must 415 always contain at least one row for an "overall" physical entity, which 416 should have an entPhysicalClass value of 'stack(11)', 'chassis(3)' or 417 'module(9)'. 419 Each row is indexed by an arbitrary, small integer, and contains a 420 description and type of the physical entity. It also optionally 421 contains the index number of another entPhysicalEntry indicating a 422 containment relationship between the two. 424 Version 2 of the Entity MIB provides additional MIB objects for each 425 physical entity. Some common read-only attributes have been added, as 426 well as three writable string objects. 428 - entPhysicalAlias 429 This string can be used by an NMS as a non-volatile identifier for 430 the physical component. Maintaining a non-volatile string for every 431 physical component represented in the entPhysicalTable can be 432 costly and unnecessary. An agent may algorithmically generate 433 'entPhysicalAlias' strings for particular entries (e.g., based on 434 the entPhysicalClass value). 436 - entPhysicalAssetID 437 This string is provided to store a user-specific asset identifier 438 for removable physical components. In order to reduce the non- 439 volatile storage needed by a particular agent, a network 440 administrator should only assign asset identifiers to physical 441 entities which are field-replaceable (i.e., not permanently 442 contained within another physical entity). 444 - entPhysicalSerialNum 445 This string is provided to store a vendor-specific serial number 446 string for physical components. This is a writable object in case 447 an agent cannot identify the serial numbers of all installed 448 physical entities, and a network administrator wishes to configure 449 the non-volatile serial number strings manually (via an NMS 450 application). 452 5.12.2. entityLogical Group 454 This group contains a single table to identify logical entities, called 455 the entLogicalTable. 457 The entLogicalTable contains one row per logical entity. Each row is 458 indexed by an arbitrary, small integer and contains a name, description, 459 and type of the logical entity. It also contains information to allow 460 access to the MIB information for the logical entity. This includes SNMP 461 versions that use a community name (with some form of implied context 462 representation) and SNMP versions that use the SNMP ARCH [RFC2571] 463 method of context identification. 465 If a agent represents multiple logical entities with this MIB, then this 466 group must be implemented for all logical entities known to the agent. 468 If an agent represents a single logical entity, or multiple logical 469 entities within a single naming scope, then implementation of this group 470 may be omitted by the agent. 472 5.12.3. entityMapping Group 474 This group contains three tables to identify associations between 475 different system components. 477 The entLPMappingTable contains mappings between entLogicalIndex values 478 (logical entities) and entPhysicalIndex values (the physical components 479 supporting that entity). A logical entity can map to more than one 480 physical component, and more than one logical entity can map to (share) 481 the same physical component. If an agent represents a single logical 482 entity, or multiple logical entities within a single naming scope, then 483 implementation of this table may be omitted by the agent. 485 The entAliasMappingTable contains mappings between entLogicalIndex, 486 entPhysicalIndex pairs and 'alias' object identifier values. This 487 allows resources managed with other MIBs (e.g., repeater ports, bridge 488 ports, physical and logical interfaces) to be identified in the physical 489 entity hierarchy. Note that each alias identifier is only relevant in a 490 particular naming scope. If an agent represents a single logical 491 entity, or multiple logical entities within a single naming scope, then 492 implementation of this table may be omitted by the agent. 494 The entPhysicalContainsTable contains simple mappings between 495 'entPhysicalContainedIn' values for each container/'containee' 496 relationship in the managed system. The indexing of this table allows an 497 NMS to quickly discover the 'entPhysicalIndex' values for all children 498 of a given physical entity. 500 5.12.4. entityGeneral Group 502 This group contains general information relating to the other object 503 groups. 505 At this time, the entGeneral group contains a single scalar object 506 (entLastChangeTime), which represents the value of sysUptime when any 507 part of the Entity MIB configuration last changed. 509 5.12.5. entityNotifications Group 511 This group contains notification definitions relating to the overall 512 status of the Entity MIB instantiation. 514 5.13. Multiple Agents 516 Even though a primary motivation for this MIB is to represent the 517 multiple logical entities supported by a single agent, it is also 518 possible to use it to represent multiple logical entities supported by 519 multiple agents (in the same "overall" physical entity). Indeed, it is 520 implicit in the SNMP architecture, that the number of agents is 521 transparent to a network management station. 523 However, there is no agreement at this time as to the degree of 524 cooperation which should be expected for agent implementations. 525 Therefore, multiple agents within the same managed system are free to 526 implement the Entity MIB independently. (Refer the section on "Multiple 527 Instances of the Entity MIB" for more details). 529 5.14. Change Log 531 The following changes have been made since publication of the original 532 Entity MIB [RFC2037]. 534 5.14.1. Version 00 536 - Clarified description of the PhysicalClass textual convention. 537 Added a new enumeration. 539 - Added RevisionString and SnmpEngineIdOrZero textual conventions to 540 support new entPhysicalTable and entLogicalTable objects 542 - Fixed bug in entPhysicalParentRelPos DESCRIPTION clause 544 - Added entPhysicalHardwareRev, FirmwareRev, and SoftwareRev objects 545 for revision identification 547 - Added entPhysicalMfgName and entPhysicalModelName objects for 548 better component identification 550 - Added entPhysicalAlias read-write string to identify specific 551 components across reboots. 553 - Added entPhysicalAssetID and entPhysicalSerialNum read-write 554 strings to allow user identification of specific components across 555 reboots. 557 - Fixed a bug in the entLogicalCommunity object. The subrange was 558 incorrect (1..255) and is now (0..255). The description clause has 559 also been clarified. This object is now deprecated. 561 - Added entLogicalContextEngineID and entLogicalContextName objects 562 to provide an SNMP context for SNMPv3 access on behalf of a logical 563 entity. 565 - Changed entLastChangeTime object description to generalize the 566 events which cause an update to the last change timestamp. 568 5.14.2. Version 01 570 - Removed the RevisionString TC. 572 - Changed the entPhysicalHardwareRev, entPhysicalFirmwareRev, and 573 entPhysicalSoftwareRev SYNTAX from RevisionString to 574 SnmpAdminString 576 - Made logical entity objects optional for agents with a single 577 'default naming scope' 579 - Fixed conformance section bugs 581 - Clarified containment rules for removable physical components 583 5.14.3. Version 02 585 - Added term definition for 'parent entity'. 587 - Added entPhysicalIsFRU object. 589 - Clarify modeling double-high modules. 591 - Clarify scope of some entPhysicalEntry attributes. 593 - Clarify instantiation guidelines of some entPhysicalTable strings. 595 - Fix typos and deleted some obsolete intro text. 597 - Relax trap throttling requirement from 'must' to 'should'. 599 - Change instances of the term 'trap' to 'notification', to align 600 with SNMPv3 terminology. 602 - Update Usage Examples section for Version 2 objects. 604 5.14.4. Version 03 606 - Added REVISION clauses to the MIB. 608 - Removed language allowing an agent to omit certain SnmpAdminString 609 based MIB instances. A zero-length string string must be returned 610 instead. 612 - Updated I-D boilerplate. 614 - Updated reference identification format. 616 5.14.5. Version 04 618 - Updated SNMP boilerplate and references. 620 - Changed 'main' naming scope to 'default' naming scope to be more 621 consistent with SNMPv3 default context. 623 - Removed the 'in-progress' REVISION clauses from the MIB. 625 - Updated Security Considerations section. 627 - Clarified some text regarding specific versions of SNMP. 629 5.14.6. Version 05 631 - Shortened the document title. 633 - Renamed the SnmpEngineIdOrZero TC to be SnmpEngineIdOrNone. 635 - Changed the entLogicalContextEngineID SYNTAX to SnmpEngineIdOrNone. 637 - Clarified description of the SnmpEngineIdOrNone TC for zero-length 638 strings. 640 5.14.7. Version 06 642 - Changed syntax from DisplayString to SnmpAdminString for the 643 entPhysicalDescr, entPhysicalName, and entLogicalDescr objects. 645 - Removed DisplayString from the IMPORTS clause. 647 - Added 'Textual Convention Change' section, which documents this 648 change. 650 6. Definitions 652 ENTITY-MIB DEFINITIONS ::= BEGIN 654 IMPORTS 655 MODULE-IDENTITY, OBJECT-TYPE, mib-2, NOTIFICATION-TYPE 656 FROM SNMPv2-SMI 657 TDomain, TAddress, TEXTUAL-CONVENTION, 658 AutonomousType, RowPointer, TimeStamp, TruthValue 659 FROM SNMPv2-TC 660 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 661 FROM SNMPv2-CONF 662 SnmpAdminString 663 FROM SNMP-FRAMEWORK-MIB; 665 entityMIB MODULE-IDENTITY 666 LAST-UPDATED "9908220000Z" 667 ORGANIZATION "IETF ENTMIB Working Group" 668 CONTACT-INFO 669 " WG E-mail: entmib@cisco.com 670 Subscribe: majordomo@cisco.com 671 msg body: subscribe entmib 673 Keith McCloghrie 674 ENTMIB Working Group Chair 675 Cisco Systems Inc. 676 170 West Tasman Drive 677 San Jose, CA 95134 678 +1 408-526-5260 679 kzm@cisco.com 681 Andy Bierman 682 ENTMIB Working Group Editor 683 Cisco Systems Inc. 684 170 West Tasman Drive 685 San Jose, CA 95134 686 +1 408-527-3711 687 abierman@cisco.com" 688 DESCRIPTION 689 "The MIB module for representing multiple logical 690 entities supported by a single SNMP agent." 691 REVISION "9908220000Z" 692 DESCRIPTION 693 "Initial Version of Entity MIB (Version 2). 694 This revision obsoletes RFC 2037. 696 This version published as RFC xxxx (to be 697 assigned by the RFC Editor)." 698 REVISION "9610310000Z" 699 DESCRIPTION 700 "Initial version (version 1), published as 701 RFC 2037." 702 ::= { mib-2 47 } 704 entityMIBObjects OBJECT IDENTIFIER ::= { entityMIB 1 } 706 -- MIB contains four groups 707 entityPhysical OBJECT IDENTIFIER ::= { entityMIBObjects 1 } 708 entityLogical OBJECT IDENTIFIER ::= { entityMIBObjects 2 } 709 entityMapping OBJECT IDENTIFIER ::= { entityMIBObjects 3 } 710 entityGeneral OBJECT IDENTIFIER ::= { entityMIBObjects 4 } 712 -- Textual Conventions 713 PhysicalIndex ::= TEXTUAL-CONVENTION 714 STATUS current 715 DESCRIPTION 716 "An arbitrary value which uniquely identifies the physical 717 entity. The value should be a small positive integer; index 718 values for different physical entities are not necessarily 719 contiguous." 720 SYNTAX INTEGER (1..2147483647) 722 PhysicalClass ::= TEXTUAL-CONVENTION 723 STATUS current 724 DESCRIPTION 725 "An enumerated value which provides an indication of the 726 general hardware type of a particular physical entity. 727 There are no restrictions as to the number of 728 entPhysicalEntries of each entPhysicalClass, which must be 729 instantiated by an agent. 731 The enumeration 'other' is applicable if the physical entity 732 class is known, but does not match any of the supported 733 values. 735 The enumeration 'unknown' is applicable if the physical 736 entity class is unknown to the agent. 738 The enumeration 'chassis' is applicable if the physical 739 entity class is an overall container for networking 740 equipment. Any class of physical entity except a stack may 741 be contained within a chassis, and a chassis may only be 742 contained within a stack. 744 The enumeration 'backplane' is applicable if the physical 745 entity class is some sort of device for aggregating and 746 forwarding networking traffic, such as a shared backplane in 747 a modular ethernet switch. Note that an agent may model a 748 backplane as a single physical entity, which is actually 749 implemented as multiple discrete physical components (within 750 a chassis or stack). 752 The enumeration 'container' is applicable if the physical 753 entity class is capable of containing one or more removable 754 physical entities, possibly of different types. For example, 755 each (empty or full) slot in a chassis will be modeled as a 756 container. Note that all removable physical entities should 757 be modeled within a container entity, such as field- 758 replaceable modules, fans, or power supplies. Note that all 759 known containers should be modeled by the agent, including 760 empty containers. 762 The enumeration 'powerSupply' is applicable if the physical 763 entity class is a power-supplying component. 765 The enumeration 'fan' is applicable if the physical entity 766 class is a fan or other heat-reduction component. 768 The enumeration 'sensor' is applicable if the physical 769 entity class is some sort of sensor, such as a temperature 770 sensor within a router chassis. 772 The enumeration 'module' is applicable if the physical 773 entity class is some sort of self-contained sub-system. If 774 it is removable, then it should be modeled within a 775 container entity, otherwise it should be modeled directly 776 within another physical entity (e.g., a chassis or another 777 module). 779 The enumeration 'port' is applicable if the physical entity 780 class is some sort of networking port, capable of receiving 781 and/or transmitting networking traffic. 783 The enumeration 'stack' is applicable if the physical entity 784 class is some sort of super-container (possibly virtual), 785 intended to group together multiple chassis entities. A 786 stack may be realized by a 'virtual' cable, a real 787 interconnect cable, attached to multiple chassis, or may in 788 fact be comprised of multiple interconnect cables. A stack 789 should not be modeled within any other physical entities, 790 but a stack may be contained within another stack. Only 791 chassis entities should be contained within a stack." 792 SYNTAX INTEGER { 793 other(1), 794 unknown(2), 795 chassis(3), 796 backplane(4), 797 container(5), -- e.g., chassis slot or daughter-card holder 798 powerSupply(6), 799 fan(7), 800 sensor(8), 801 module(9), -- e.g., plug-in card or daughter-card 802 port(10), 803 stack(11) -- e.g., stack of multiple chassis entities 804 } 806 SnmpEngineIdOrNone ::= TEXTUAL-CONVENTION 807 STATUS current 808 DESCRIPTION 809 "A specially formatted SnmpEngineID string for use with the 810 Entity MIB. 812 If an instance of an object of SYNTAX SnmpEngineIdOrNone has 813 a non-zero length, then the object encoding and semantics 814 are defined by the SnmpEngineID textual convention (see RFC 815 2571 [RFC2571]). 817 If an instance of an object of SYNTAX SnmpEngineIdOrNone 818 contains a zero-length string, then no appropriate 819 SnmpEngineID is associated with the logical entity (i.e., 820 SNMPv3 not supported)." 821 SYNTAX OCTET STRING (SIZE(0..32)) -- empty string or SnmpEngineID 823 -- The Physical Entity Table 824 entPhysicalTable OBJECT-TYPE 825 SYNTAX SEQUENCE OF EntPhysicalEntry 826 MAX-ACCESS not-accessible 827 STATUS current 828 DESCRIPTION 829 "This table contains one row per physical entity. There is 830 always at least one row for an 'overall' physical entity." 831 ::= { entityPhysical 1 } 833 entPhysicalEntry OBJECT-TYPE 834 SYNTAX EntPhysicalEntry 835 MAX-ACCESS not-accessible 836 STATUS current 837 DESCRIPTION 838 "Information about a particular physical entity. 840 Each entry provides objects (entPhysicalDescr, 841 entPhysicalVendorType, and entPhysicalClass) to help an NMS 842 identify and characterize the entry, and objects 843 (entPhysicalContainedIn and entPhysicalParentRelPos) to help 844 an NMS relate the particular entry to other entries in this 845 table." 846 INDEX { entPhysicalIndex } 847 ::= { entPhysicalTable 1 } 849 EntPhysicalEntry ::= SEQUENCE { 850 entPhysicalIndex PhysicalIndex, 851 entPhysicalDescr SnmpAdminString, 852 entPhysicalVendorType AutonomousType, 853 entPhysicalContainedIn INTEGER, 854 entPhysicalClass PhysicalClass, 855 entPhysicalParentRelPos INTEGER, 856 entPhysicalName SnmpAdminString, 857 entPhysicalHardwareRev SnmpAdminString, 858 entPhysicalFirmwareRev SnmpAdminString, 859 entPhysicalSoftwareRev SnmpAdminString, 860 entPhysicalSerialNum SnmpAdminString, 861 entPhysicalMfgName SnmpAdminString, 862 entPhysicalModelName SnmpAdminString, 863 entPhysicalAlias SnmpAdminString, 864 entPhysicalAssetID SnmpAdminString, 865 entPhysicalIsFRU TruthValue 866 } 868 entPhysicalIndex OBJECT-TYPE 869 SYNTAX PhysicalIndex 870 MAX-ACCESS not-accessible 871 STATUS current 872 DESCRIPTION 873 "The index for this entry." 874 ::= { entPhysicalEntry 1 } 876 entPhysicalDescr OBJECT-TYPE 877 SYNTAX SnmpAdminString 878 MAX-ACCESS read-only 879 STATUS current 880 DESCRIPTION 881 "A textual description of physical entity. This object 882 should contain a string which identifies the manufacturer's 883 name for the physical entity, and should be set to a 884 distinct value for each version or model of the physical 885 entity. " 886 ::= { entPhysicalEntry 2 } 888 entPhysicalVendorType OBJECT-TYPE 889 SYNTAX AutonomousType 890 MAX-ACCESS read-only 891 STATUS current 892 DESCRIPTION 893 "An indication of the vendor-specific hardware type of the 894 physical entity. Note that this is different from the 895 definition of MIB-II's sysObjectID. 897 An agent should set this object to a enterprise-specific 898 registration identifier value indicating the specific 899 equipment type in detail. The associated instance of 900 entPhysicalClass is used to indicate the general type of 901 hardware device. 903 If no vendor-specific registration identifier exists for 904 this physical entity, or the value is unknown by this agent, 905 then the value { 0 0 } is returned." 906 ::= { entPhysicalEntry 3 } 908 entPhysicalContainedIn OBJECT-TYPE 909 SYNTAX INTEGER (0..2147483647) 910 MAX-ACCESS read-only 911 STATUS current 912 DESCRIPTION 913 "The value of entPhysicalIndex for the physical entity which 914 'contains' this physical entity. A value of zero indicates 915 this physical entity is not contained in any other physical 916 entity. Note that the set of 'containment' relationships 917 define a strict hierarchy; that is, recursion is not 918 allowed. 920 In the event a physical entity is contained by more than one 921 physical entity (e.g., double-wide modules), this object 922 should identify the containing entity with the lowest value 923 of entPhysicalIndex." 924 ::= { entPhysicalEntry 4 } 926 entPhysicalClass OBJECT-TYPE 927 SYNTAX PhysicalClass 928 MAX-ACCESS read-only 929 STATUS current 930 DESCRIPTION 931 "An indication of the general hardware type of the physical 932 entity. 934 An agent should set this object to the standard enumeration 935 value which most accurately indicates the general class of 936 the physical entity, or the primary class if there is more 937 than one. 939 If no appropriate standard registration identifier exists 940 for this physical entity, then the value 'other(1)' is 941 returned. If the value is unknown by this agent, then the 942 value 'unknown(2)' is returned." 943 ::= { entPhysicalEntry 5 } 945 entPhysicalParentRelPos OBJECT-TYPE 946 SYNTAX INTEGER (-1..2147483647) 947 MAX-ACCESS read-only 948 STATUS current 949 DESCRIPTION 950 "An indication of the relative position of this 'child' 951 component among all its 'sibling' components. Sibling 952 components are defined as entPhysicalEntries which share the 953 same instance values of each of the entPhysicalContainedIn 954 and entPhysicalClass objects. 956 An NMS can use this object to identify the relative ordering 957 for all sibling components of a particular parent 958 (identified by the entPhysicalContainedIn instance in each 959 sibling entry). 961 This value should match any external labeling of the 962 physical component if possible. For example, for a container 963 (e.g., card slot) labeled as 'slot #3', 964 entPhysicalParentRelPos should have the value '3'. Note 965 that the entPhysicalEntry for the module plugged in slot 3 966 should have an entPhysicalParentRelPos value of '1'. 968 If the physical position of this component does not match 969 any external numbering or clearly visible ordering, then 970 user documentation or other external reference material 971 should be used to determine the parent-relative position. If 972 this is not possible, then the the agent should assign a 973 consistent (but possibly arbitrary) ordering to a given set 974 of 'sibling' components, perhaps based on internal 975 representation of the components. 977 If the agent cannot determine the parent-relative position 978 for some reason, or if the associated value of 979 entPhysicalContainedIn is '0', then the value '-1' is 980 returned. Otherwise a non-negative integer is returned, 981 indicating the parent-relative position of this physical 982 entity. 984 Parent-relative ordering normally starts from '1' and 985 continues to 'N', where 'N' represents the highest 986 positioned child entity. However, if the physical entities 987 (e.g., slots) are labeled from a starting position of zero, 988 then the first sibling should be associated with a 989 entPhysicalParentRelPos value of '0'. Note that this 990 ordering may be sparse or dense, depending on agent 991 implementation. 993 The actual values returned are not globally meaningful, as 994 each 'parent' component may use different numbering 995 algorithms. The ordering is only meaningful among siblings 996 of the same parent component. 998 The agent should retain parent-relative position values 999 across reboots, either through algorithmic assignment or use 1000 of non-volatile storage." 1001 ::= { entPhysicalEntry 6 } 1003 entPhysicalName OBJECT-TYPE 1004 SYNTAX SnmpAdminString 1005 MAX-ACCESS read-only 1006 STATUS current 1007 DESCRIPTION 1008 "The textual name of the physical entity. The value of this 1009 object should be the name of the component as assigned by 1010 the local device and should be suitable for use in commands 1011 entered at the device's `console'. This might be a text 1012 name, such as `console' or a simple component number (e.g., 1013 port or module number), such as `1', depending on the 1014 physical component naming syntax of the device. 1016 If there is no local name, or this object is otherwise not 1017 applicable, then this object contains a zero-length string. 1019 Note that the value of entPhysicalName for two physical 1020 entities will be the same in the event that the console 1021 interface does not distinguish between them, e.g., slot-1 1022 and the card in slot-1." 1023 ::= { entPhysicalEntry 7 } 1025 entPhysicalHardwareRev OBJECT-TYPE 1026 SYNTAX SnmpAdminString 1027 MAX-ACCESS read-only 1028 STATUS current 1029 DESCRIPTION 1030 "The vendor-specific hardware revision string for the 1031 physical entity. The preferred value is the hardware 1032 revision identifier actually printed on the component itself 1033 (if present). 1035 Note that if revision information is stored internally in a 1036 non-printable (e.g., binary) format, then the agent must 1037 convert such information to a printable format, in an 1038 implementation-specific manner. 1040 If no specific hardware revision string is associated with 1041 the physical component, or this information is unknown to 1042 the agent, then this object will contain a zero-length 1043 string." 1044 ::= { entPhysicalEntry 8 } 1046 entPhysicalFirmwareRev OBJECT-TYPE 1047 SYNTAX SnmpAdminString 1048 MAX-ACCESS read-only 1049 STATUS current 1050 DESCRIPTION 1051 "The vendor-specific firmware revision string for the 1052 physical entity. 1054 Note that if revision information is stored internally in a 1055 non-printable (e.g., binary) format, then the agent must 1056 convert such information to a printable format, in an 1057 implementation-specific manner. 1059 If no specific firmware programs are associated with the 1060 physical component, or this information is unknown to the 1061 agent, then this object will contain a zero-length string." 1062 ::= { entPhysicalEntry 9 } 1064 entPhysicalSoftwareRev OBJECT-TYPE 1065 SYNTAX SnmpAdminString 1066 MAX-ACCESS read-only 1067 STATUS current 1068 DESCRIPTION 1069 "The vendor-specific software revision string for the 1070 physical entity. 1072 Note that if revision information is stored internally in a 1073 non-printable (e.g., binary) format, then the agent must 1074 convert such information to a printable format, in an 1075 implementation-specific manner. 1077 If no specific software programs are associated with the 1078 physical component, or this information is unknown to the 1079 agent, then this object will contain a zero-length string." 1080 ::= { entPhysicalEntry 10 } 1082 entPhysicalSerialNum OBJECT-TYPE 1083 SYNTAX SnmpAdminString (SIZE (0..32)) 1084 MAX-ACCESS read-write 1085 STATUS current 1086 DESCRIPTION 1087 "The vendor-specific serial number string for the physical 1088 entity. The preferred value is the serial number string 1089 actually printed on the component itself (if present). 1091 On the first instantiation of an physical entity, the value 1092 of entPhysicalSerialNum associated with that entity is set 1093 to the correct vendor-assigned serial number, if this 1094 information is available to the agent. If a serial number 1095 is unknown or non-existent, the entPhysicalSerialNum will be 1096 set to a zero-length string instead. 1098 Note that implementations which can correctly identify the 1099 serial numbers of all installed physical entities do not 1100 need to provide write access to the entPhysicalSerialNum 1101 object. Agents which cannot provide non-volatile storage for 1102 the entPhysicalSerialNum strings are not required to 1103 implement write access for this object. 1105 Not every physical component will have a serial number, or 1106 even need one. Physical entities for which the associated 1107 value of the entPhysicalIsFRU object is equal to 'false(2)' 1108 (e.g., the repeater ports within a repeater module), do not 1109 need their own unique serial number. An agent does not have 1110 to provide write access for such entities, and may return a 1111 zero-length string. 1113 If write access is implemented for an instance of 1114 entPhysicalSerialNum, and a value is written into the 1115 instance, the agent must retain the supplied value in the 1116 entPhysicalSerialNum instance associated with the same 1117 physical entity for as long as that entity remains 1118 instantiated. This includes instantiations across all re- 1119 initializations/reboots of the network management system, 1120 including those which result in a change of the physical 1121 entity's entPhysicalIndex value." 1122 ::= { entPhysicalEntry 11 } 1124 entPhysicalMfgName OBJECT-TYPE 1125 SYNTAX SnmpAdminString 1126 MAX-ACCESS read-only 1127 STATUS current 1128 DESCRIPTION 1129 "The name of the manufacturer of this physical component. 1130 The preferred value is the manufacturer name string actually 1131 printed on the component itself (if present). 1133 Note that comparisons between instances of the 1134 entPhysicalModelName, entPhysicalFirmwareRev, 1135 entPhysicalSoftwareRev, and the entPhysicalSerialNum 1136 objects, are only meaningful amongst entPhysicalEntries with 1137 the same value of entPhysicalMfgName. 1139 If the manufacturer name string associated with the physical 1140 component is unknown to the agent, then this object will 1141 contain a zero-length string." 1142 ::= { entPhysicalEntry 12 } 1144 entPhysicalModelName OBJECT-TYPE 1145 SYNTAX SnmpAdminString 1146 MAX-ACCESS read-only 1147 STATUS current 1148 DESCRIPTION 1149 "The vendor-specific model name identifier string associated 1150 with this physical component. The preferred value is the 1151 customer-visible part number, which may be printed on the 1152 component itself. 1154 If the model name string associated with the physical 1155 component is unknown to the agent, then this object will 1156 contain a zero-length string." 1157 ::= { entPhysicalEntry 13 } 1159 entPhysicalAlias OBJECT-TYPE 1160 SYNTAX SnmpAdminString (SIZE (0..32)) 1161 MAX-ACCESS read-write 1162 STATUS current 1163 DESCRIPTION 1164 "This object is an 'alias' name for the physical entity as 1165 specified by a network manager, and provides a non-volatile 1166 'handle' for the physical entity. 1168 On the first instantiation of an physical entity, the value 1169 of entPhysicalAlias associated with that entity is set to 1170 the zero-length string. However, agent may set the value to 1171 a locally unique default value, instead of a zero-length 1172 string. 1174 If write access is implemented for an instance of 1175 entPhysicalAlias, and a value is written into the instance, 1176 the agent must retain the supplied value in the 1177 entPhysicalAlias instance associated with the same physical 1178 entity for as long as that entity remains instantiated. 1179 This includes instantiations across all re- 1180 initializations/reboots of the network management system, 1181 including those which result in a change of the physical 1182 entity's entPhysicalIndex value." 1183 ::= { entPhysicalEntry 14 } 1185 entPhysicalAssetID OBJECT-TYPE 1186 SYNTAX SnmpAdminString (SIZE (0..32)) 1187 MAX-ACCESS read-write 1188 STATUS current 1189 DESCRIPTION 1190 "This object is a user-assigned asset tracking identifier 1191 for the physical entity as specified by a network manager, 1192 and provides non-volatile storage of this information. 1194 On the first instantiation of an physical entity, the value 1195 of entPhysicalAssetID associated with that entity is set to 1196 the zero-length string. 1198 Not every physical component will have a asset tracking 1199 identifier, or even need one. Physical entities for which 1200 the associated value of the entPhysicalIsFRU object is equal 1201 to 'false(2)' (e.g., the repeater ports within a repeater 1202 module), do not need their own unique asset tracking 1203 identifier. An agent does not have to provide write access 1204 for such entities, and may instead return a zero-length 1205 string. 1207 If write access is implemented for an instance of 1208 entPhysicalAssetID, and a value is written into the 1209 instance, the agent must retain the supplied value in the 1210 entPhysicalAssetID instance associated with the same 1211 physical entity for as long as that entity remains 1212 instantiated. This includes instantiations across all re- 1213 initializations/reboots of the network management system, 1214 including those which result in a change of the physical 1215 entity's entPhysicalIndex value. 1217 If no asset tracking information is associated with the 1218 physical component, then this object will contain a zero- 1219 length string." 1220 ::= { entPhysicalEntry 15 } 1222 entPhysicalIsFRU OBJECT-TYPE 1223 SYNTAX TruthValue 1224 MAX-ACCESS read-only 1225 STATUS current 1226 DESCRIPTION 1227 "This object indicates whether or not this physical entity 1228 is considered a 'field replaceable unit' by the vendor. If 1229 this object contains the value 'true(1)' then this 1230 entPhysicalEntry identifies a field replaceable unit. For 1231 all entPhysicalEntries which represent components that are 1232 permanently contained within a field replaceable unit, the 1233 value 'false(2)' should be returned for this object." 1235 ::= { entPhysicalEntry 16 } 1237 -- The Logical Entity Table 1238 entLogicalTable OBJECT-TYPE 1239 SYNTAX SEQUENCE OF EntLogicalEntry 1240 MAX-ACCESS not-accessible 1241 STATUS current 1242 DESCRIPTION 1243 "This table contains one row per logical entity. For agents 1244 which implement more than one naming scope, at least one 1245 entry must exist. Agents which instantiate all MIB objects 1246 within a single naming scope are not required to implement 1247 this table." 1248 ::= { entityLogical 1 } 1250 entLogicalEntry OBJECT-TYPE 1251 SYNTAX EntLogicalEntry 1252 MAX-ACCESS not-accessible 1253 STATUS current 1254 DESCRIPTION 1255 "Information about a particular logical entity. Entities 1256 may be managed by this agent or other SNMP agents (possibly) 1257 in the same chassis." 1258 INDEX { entLogicalIndex } 1259 ::= { entLogicalTable 1 } 1261 EntLogicalEntry ::= SEQUENCE { 1262 entLogicalIndex INTEGER, 1263 entLogicalDescr SnmpAdminString, 1264 entLogicalType AutonomousType, 1265 entLogicalCommunity OCTET STRING, 1266 entLogicalTAddress TAddress, 1267 entLogicalTDomain TDomain, 1268 entLogicalContextEngineID SnmpEngineIdOrNone, 1269 entLogicalContextName SnmpAdminString 1270 } 1272 entLogicalIndex OBJECT-TYPE 1273 SYNTAX INTEGER (1..2147483647) 1274 MAX-ACCESS not-accessible 1275 STATUS current 1276 DESCRIPTION 1277 "The value of this object uniquely identifies the logical 1278 entity. The value should be a small positive integer; index 1279 values for different logical entities are are not 1280 necessarily contiguous." 1281 ::= { entLogicalEntry 1 } 1283 entLogicalDescr OBJECT-TYPE 1284 SYNTAX SnmpAdminString 1285 MAX-ACCESS read-only 1286 STATUS current 1287 DESCRIPTION 1288 "A textual description of the logical entity. This object 1289 should contain a string which identifies the manufacturer's 1290 name for the logical entity, and should be set to a distinct 1291 value for each version of the logical entity. " 1292 ::= { entLogicalEntry 2 } 1294 entLogicalType OBJECT-TYPE 1295 SYNTAX AutonomousType 1296 MAX-ACCESS read-only 1297 STATUS current 1298 DESCRIPTION 1299 "An indication of the type of logical entity. This will 1300 typically be the OBJECT IDENTIFIER name of the node in the 1301 SMI's naming hierarchy which represents the major MIB 1302 module, or the majority of the MIB modules, supported by the 1303 logical entity. For example: 1304 a logical entity of a regular host/router -> mib-2 1305 a logical entity of a 802.1d bridge -> dot1dBridge 1306 a logical entity of a 802.3 repeater -> snmpDot3RptrMgmt 1307 If an appropriate node in the SMI's naming hierarchy cannot 1308 be identified, the value 'mib-2' should be used." 1309 ::= { entLogicalEntry 3 } 1311 entLogicalCommunity OBJECT-TYPE 1312 SYNTAX OCTET STRING (SIZE (0..255)) 1313 MAX-ACCESS read-only 1314 STATUS deprecated 1315 DESCRIPTION 1316 "An SNMPv1 or SNMPv2C community-string which can be used to 1317 access detailed management information for this logical 1318 entity. The agent should allow read access with this 1319 community string (to an appropriate subset of all managed 1320 objects) and may also return a community string based on the 1321 privileges of the request used to read this object. Note 1322 that an agent may return a community string with read-only 1323 privileges, even if this object is accessed with a read- 1324 write community string. However, the agent must take care 1325 not to return a community string which allows more 1326 privileges than the community string used to access this 1327 object. 1329 A compliant SNMP agent may wish to conserve naming scopes by 1330 representing multiple logical entities in a single 'default' 1331 naming scope. This is possible when the logical entities 1332 represented by the same value of entLogicalCommunity have no 1333 object instances in common. For example, 'bridge1' and 1334 'repeater1' may be part of the main naming scope, but at 1335 least one additional community string is needed to represent 1336 'bridge2' and 'repeater2'. 1338 Logical entities 'bridge1' and 'repeater1' would be 1339 represented by sysOREntries associated with the 'default' 1340 naming scope. 1342 For agents not accessible via SNMPv1 or SNMPv2C, the value 1343 of this object is the empty string. This object may also 1344 contain an empty string if a community string has not yet 1345 been assigned by the agent, or no community string with 1346 suitable access rights can be returned for a particular SNMP 1347 request. 1349 Note that this object is deprecated. Agents which implement 1350 SNMPv3 access should use the entLogicalContextEngineID and 1351 entLogicalContextName objects to identify the context 1352 associated with each logical entity. SNMPv3 agents may 1353 return a zero-length string for this object, or may continue 1354 to return a community string (e.g., tri-lingual agent 1355 support)." 1356 ::= { entLogicalEntry 4 } 1358 entLogicalTAddress OBJECT-TYPE 1359 SYNTAX TAddress 1360 MAX-ACCESS read-only 1361 STATUS current 1362 DESCRIPTION 1363 "The transport service address by which the logical entity 1364 receives network management traffic, formatted according to 1365 the corresponding value of entLogicalTDomain. 1367 For snmpUDPDomain, a TAddress is 6 octets long, the initial 1368 4 octets containing the IP-address in network-byte order and 1369 the last 2 containing the UDP port in network-byte order. 1370 Consult 'Transport Mappings for Version 2 of the Simple 1371 Network Management Protocol' (RFC 1906 [RFC1906]) for 1372 further information on snmpUDPDomain." 1373 ::= { entLogicalEntry 5 } 1375 entLogicalTDomain OBJECT-TYPE 1376 SYNTAX TDomain 1377 MAX-ACCESS read-only 1378 STATUS current 1379 DESCRIPTION 1380 "Indicates the kind of transport service by which the 1381 logical entity receives network management traffic. 1382 Possible values for this object are presently found in the 1383 Transport Mappings for SNMPv2 document (RFC 1906 1384 [RFC1906])." 1385 ::= { entLogicalEntry 6 } 1387 entLogicalContextEngineID OBJECT-TYPE 1388 SYNTAX SnmpEngineIdOrNone 1389 MAX-ACCESS read-only 1390 STATUS current 1391 DESCRIPTION 1392 "The authoritative contextEngineID that can be used to send 1393 an SNMP message concerning information held by this logical 1394 entity, to the address specified by the associated 1395 'entLogicalTAddress/entLogicalTDomain' pair. 1397 This object, together with the associated 1398 entLogicalContextName object, defines the context associated 1399 with a particular logical entity, and allows access to SNMP 1400 engines identified by a contextEngineId and contextName 1401 pair. 1403 If no value has been configured by the agent, a zero-length 1404 string is returned, or the agent may choose not to 1405 instantiate this object at all." 1406 ::= { entLogicalEntry 7 } 1408 entLogicalContextName OBJECT-TYPE 1409 SYNTAX SnmpAdminString 1410 MAX-ACCESS read-only 1411 STATUS current 1412 DESCRIPTION 1413 "The contextName that can be used to send an SNMP message 1414 concerning information held by this logical entity, to the 1415 address specified by the associated 1416 'entLogicalTAddress/entLogicalTDomain' pair. 1418 This object, together with the associated 1419 entLogicalContextEngineID object, defines the context 1420 associated with a particular logical entity, and allows 1421 access to SNMP engines identified by a contextEngineId and 1422 contextName pair. 1424 If no value has been configured by the agent, a zero-length 1425 string is returned, or the agent may choose not to 1426 instantiate this object at all." 1427 ::= { entLogicalEntry 8 } 1429 entLPMappingTable OBJECT-TYPE 1430 SYNTAX SEQUENCE OF EntLPMappingEntry 1431 MAX-ACCESS not-accessible 1432 STATUS current 1433 DESCRIPTION 1434 "This table contains zero or more rows of logical entity to 1435 physical equipment associations. For each logical entity 1436 known by this agent, there are zero or more mappings to the 1437 physical resources which are used to realize that logical 1438 entity. 1440 An agent should limit the number and nature of entries in 1441 this table such that only meaningful and non-redundant 1442 information is returned. For example, in a system which 1443 contains a single power supply, mappings between logical 1444 entities and the power supply are not useful and should not 1445 be included. 1447 Also, only the most appropriate physical component which is 1448 closest to the root of a particular containment tree should 1449 be identified in an entLPMapping entry. 1451 For example, suppose a bridge is realized on a particular 1452 module, and all ports on that module are ports on this 1453 bridge. A mapping between the bridge and the module would be 1454 useful, but additional mappings between the bridge and each 1455 of the ports on that module would be redundant (since the 1456 entPhysicalContainedIn hierarchy can provide the same 1457 information). If, on the other hand, more than one bridge 1458 was utilizing ports on this module, then mappings between 1459 each bridge and the ports it used would be appropriate. 1461 Also, in the case of a single backplane repeater, a mapping 1462 for the backplane to the single repeater entity is not 1463 necessary." 1464 ::= { entityMapping 1 } 1466 entLPMappingEntry OBJECT-TYPE 1467 SYNTAX EntLPMappingEntry 1468 MAX-ACCESS not-accessible 1469 STATUS current 1470 DESCRIPTION 1471 "Information about a particular logical entity to physical 1472 equipment association. Note that the nature of the 1473 association is not specifically identified in this entry. 1474 It is expected that sufficient information exists in the 1475 MIBs used to manage a particular logical entity to infer how 1476 physical component information is utilized." 1477 INDEX { entLogicalIndex, entLPPhysicalIndex } 1478 ::= { entLPMappingTable 1 } 1480 EntLPMappingEntry ::= SEQUENCE { 1481 entLPPhysicalIndex PhysicalIndex 1482 } 1484 entLPPhysicalIndex OBJECT-TYPE 1485 SYNTAX PhysicalIndex 1486 MAX-ACCESS read-only 1487 STATUS current 1488 DESCRIPTION 1489 "The value of this object identifies the index value of a 1490 particular entPhysicalEntry associated with the indicated 1491 entLogicalEntity." 1492 ::= { entLPMappingEntry 1 } 1494 -- logical entity/component to alias table 1495 entAliasMappingTable OBJECT-TYPE 1496 SYNTAX SEQUENCE OF EntAliasMappingEntry 1497 MAX-ACCESS not-accessible 1498 STATUS current 1499 DESCRIPTION 1500 "This table contains zero or more rows, representing 1501 mappings of logical entity and physical component to 1502 external MIB identifiers. Each physical port in the system 1503 may be associated with a mapping to an external identifier, 1504 which itself is associated with a particular logical 1505 entity's naming scope. A 'wildcard' mechanism is provided 1506 to indicate that an identifier is associated with more than 1507 one logical entity." 1508 ::= { entityMapping 2 } 1510 entAliasMappingEntry OBJECT-TYPE 1511 SYNTAX EntAliasMappingEntry 1512 MAX-ACCESS not-accessible 1513 STATUS current 1514 DESCRIPTION 1515 "Information about a particular physical equipment, logical 1516 entity to external identifier binding. Each logical 1517 entity/physical component pair may be associated with one 1518 alias mapping. The logical entity index may also be used as 1519 a 'wildcard' (refer to the entAliasLogicalIndexOrZero object 1520 DESCRIPTION clause for details.) 1522 Note that only entPhysicalIndex values which represent 1523 physical ports (i.e. associated entPhysicalClass value is 1524 'port(10)') are permitted to exist in this table." 1525 INDEX { entPhysicalIndex, entAliasLogicalIndexOrZero } 1526 ::= { entAliasMappingTable 1 } 1528 EntAliasMappingEntry ::= SEQUENCE { 1529 entAliasLogicalIndexOrZero INTEGER, 1530 entAliasMappingIdentifier RowPointer 1531 } 1533 entAliasLogicalIndexOrZero OBJECT-TYPE 1534 SYNTAX INTEGER (0..2147483647) 1535 MAX-ACCESS not-accessible 1536 STATUS current 1537 DESCRIPTION 1538 "The value of this object identifies the logical entity 1539 which defines the naming scope for the associated instance 1540 of the 'entAliasMappingIdentifier' object. 1542 If this object has a non-zero value, then it identifies the 1543 logical entity named by the same value of entLogicalIndex. 1545 If this object has a value of zero, then the mapping between 1546 the physical component and the alias identifier for this 1547 entAliasMapping entry is associated with all unspecified 1548 logical entities. That is, a value of zero (the default 1549 mapping) identifies any logical entity which does not have 1550 an explicit entry in this table for a particular 1551 entPhysicalIndex/entAliasMappingIdentifier pair. 1553 For example, to indicate that a particular interface (e.g., 1554 physical component 33) is identified by the same value of 1555 ifIndex for all logical entities, the following instance 1556 might exist: 1558 entAliasMappingIdentifier.33.0 = ifIndex.5 1560 In the event an entPhysicalEntry is associated differently 1561 for some logical entities, additional entAliasMapping 1562 entries may exist, e.g.: 1564 entAliasMappingIdentifier.33.0 = ifIndex.6 1565 entAliasMappingIdentifier.33.4 = ifIndex.1 1566 entAliasMappingIdentifier.33.5 = ifIndex.1 1567 entAliasMappingIdentifier.33.10 = ifIndex.12 1569 Note that entries with non-zero entAliasLogicalIndexOrZero 1570 index values have precedence over any zero-indexed entry. In 1571 this example, all logical entities except 4, 5, and 10, 1572 associate physical entity 33 with ifIndex.6." 1573 ::= { entAliasMappingEntry 1 } 1575 entAliasMappingIdentifier OBJECT-TYPE 1576 SYNTAX RowPointer 1577 MAX-ACCESS read-only 1578 STATUS current 1579 DESCRIPTION 1580 "The value of this object identifies a particular conceptual 1581 row associated with the indicated entPhysicalIndex and 1582 entLogicalIndex pair. 1584 Since only physical ports are modeled in this table, only 1585 entries which represent interfaces or ports are allowed. If 1586 an ifEntry exists on behalf of a particular physical port, 1587 then this object should identify the associated 'ifEntry'. 1588 For repeater ports, the appropriate row in the 1589 'rptrPortGroupTable' should be identified instead. 1591 For example, suppose a physical port was represented by 1592 entPhysicalEntry.3, entLogicalEntry.15 existed for a 1593 repeater, and entLogicalEntry.22 existed for a bridge. Then 1594 there might be two related instances of 1595 entAliasMappingIdentifier: 1596 entAliasMappingIdentifier.3.15 == rptrPortGroupIndex.5.2 1597 entAliasMappingIdentifier.3.22 == ifIndex.17 1598 It is possible that other mappings (besides interfaces and 1599 repeater ports) may be defined in the future, as required. 1601 Bridge ports are identified by examining the Bridge MIB and 1602 appropriate ifEntries associated with each 'dot1dBasePort', 1603 and are thus not represented in this table." 1604 ::= { entAliasMappingEntry 2 } 1606 -- physical mapping table 1607 entPhysicalContainsTable OBJECT-TYPE 1608 SYNTAX SEQUENCE OF EntPhysicalContainsEntry 1609 MAX-ACCESS not-accessible 1610 STATUS current 1611 DESCRIPTION 1612 "A table which exposes the container/'containee' 1613 relationships between physical entities. This table provides 1614 all the information found by constructing the virtual 1615 containment tree for a given entPhysicalTable, but in a more 1616 direct format. 1618 In the event a physical entity is contained by more than one 1619 other physical entity (e.g., double-wide modules), this 1620 table should include these additional mappings, which cannot 1621 be represented in the entPhysicalTable virtual containment 1622 tree." 1623 ::= { entityMapping 3 } 1625 entPhysicalContainsEntry OBJECT-TYPE 1626 SYNTAX EntPhysicalContainsEntry 1627 MAX-ACCESS not-accessible 1628 STATUS current 1629 DESCRIPTION 1630 "A single container/'containee' relationship." 1631 INDEX { entPhysicalIndex, entPhysicalChildIndex } 1632 ::= { entPhysicalContainsTable 1 } 1634 EntPhysicalContainsEntry ::= SEQUENCE { 1635 entPhysicalChildIndex PhysicalIndex 1636 } 1637 entPhysicalChildIndex OBJECT-TYPE 1638 SYNTAX PhysicalIndex 1639 MAX-ACCESS read-only 1640 STATUS current 1641 DESCRIPTION 1642 "The value of entPhysicalIndex for the contained physical 1643 entity." 1644 ::= { entPhysicalContainsEntry 1 } 1646 -- last change time stamp for the whole MIB 1647 entLastChangeTime OBJECT-TYPE 1648 SYNTAX TimeStamp 1649 MAX-ACCESS read-only 1650 STATUS current 1651 DESCRIPTION 1652 "The value of sysUpTime at the time a conceptual row is 1653 created, modified, or deleted in any of these tables: 1654 - entPhysicalTable 1655 - entLogicalTable 1656 - entLPMappingTable 1657 - entAliasMappingTable 1658 - entPhysicalContainsTable 1659 " 1660 ::= { entityGeneral 1 } 1662 -- Entity MIB Trap Definitions 1663 entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } 1664 entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } 1666 entConfigChange NOTIFICATION-TYPE 1667 STATUS current 1668 DESCRIPTION 1669 "An entConfigChange notification is generated when the value 1670 of entLastChangeTime changes. It can be utilized by an NMS 1671 to trigger logical/physical entity table maintenance polls. 1673 An agent should not generate more than one entConfigChange 1674 'notification-event' in a given time interval (five seconds 1675 is the suggested default). A 'notification-event' is the 1676 transmission of a single trap or inform PDU to a list of 1677 notification destinations. 1679 If additional configuration changes occur within the 1680 throttling period, then notification-events for these 1681 changes should be suppressed by the agent until the current 1682 throttling period expires. At the end of a throttling 1683 period, one notification-event should be generated if any 1684 configuration changes occurred since the start of the 1685 throttling period. In such a case, another throttling period 1686 is started right away. 1688 An NMS should periodically check the value of 1689 entLastChangeTime to detect any missed entConfigChange 1690 notification-events, e.g., due to throttling or transmission 1691 loss." 1692 ::= { entityMIBTrapPrefix 1 } 1694 -- conformance information 1695 entityConformance OBJECT IDENTIFIER ::= { entityMIB 3 } 1697 entityCompliances OBJECT IDENTIFIER ::= { entityConformance 1 } 1698 entityGroups OBJECT IDENTIFIER ::= { entityConformance 2 } 1700 -- compliance statements 1701 entityCompliance MODULE-COMPLIANCE 1702 STATUS deprecated 1703 DESCRIPTION 1704 "The compliance statement for SNMP entities which implement 1705 version 1 of the Entity MIB." 1706 MODULE -- this module 1707 MANDATORY-GROUPS { 1708 entityPhysicalGroup, 1709 entityLogicalGroup, 1710 entityMappingGroup, 1711 entityGeneralGroup, 1712 entityNotificationsGroup 1713 } 1714 ::= { entityCompliances 1 } 1716 entity2Compliance MODULE-COMPLIANCE 1717 STATUS current 1718 DESCRIPTION 1719 "The compliance statement for SNMP entities which implement 1720 version 2 of the Entity MIB." 1721 MODULE -- this module 1722 MANDATORY-GROUPS { 1723 entityPhysicalGroup, 1724 entityPhysical2Group, 1725 entityGeneralGroup, 1726 entityNotificationsGroup 1727 } 1728 GROUP entityLogical2Group 1729 DESCRIPTION 1730 "Implementation of this group is not mandatory for agents 1731 which model all MIB object instances within a single naming 1732 scope." 1734 GROUP entityMappingGroup 1735 DESCRIPTION 1736 "Implementation of the entPhysicalContainsTable is mandatory 1737 for all agents. Implementation of the entLPMappingTable and 1738 entAliasMappingTables are not mandatory for agents which 1739 model all MIB object instances within a single naming scope. 1741 Note that the entAliasMappingTable may be useful for all 1742 agents, however implementation of the entityLogicalGroup or 1743 entityLogical2Group is required to support this table." 1745 OBJECT entPhysicalSerialNum 1746 MIN-ACCESS not-accessible 1747 DESCRIPTION 1748 "Read and write access is not required for agents which 1749 cannot identify serial number information for physical 1750 entities, and/or cannot provide non-volatile storage for 1751 NMS-assigned serial numbers. 1753 Write access is not required for agents which can identify 1754 serial number information for physical entities, but cannot 1755 provide non-volatile storage for NMS-assigned serial 1756 numbers. 1758 Write access is not required for physical entities for 1759 physical entities for which the associated value of the 1760 entPhysicalIsFRU object is equal to 'false(2)'." 1762 OBJECT entPhysicalAlias 1763 MIN-ACCESS read-only 1764 DESCRIPTION 1765 "Write access is required only if the associated 1766 entPhysicalClass value is equal to 'chassis(3)'." 1768 OBJECT entPhysicalAssetID 1769 MIN-ACCESS not-accessible 1770 DESCRIPTION 1771 "Read and write access is not required for agents which 1772 cannot provide non-volatile storage for NMS-assigned asset 1773 identifiers. 1775 Write access is not required for physical entities for which 1776 the associated value of entPhysicalIsFRU is equal to 1777 'false(2)'." 1778 ::= { entityCompliances 2 } 1780 -- MIB groupings 1781 entityPhysicalGroup OBJECT-GROUP 1782 OBJECTS { 1783 entPhysicalDescr, 1784 entPhysicalVendorType, 1785 entPhysicalContainedIn, 1786 entPhysicalClass, 1787 entPhysicalParentRelPos, 1788 entPhysicalName 1789 } 1790 STATUS current 1791 DESCRIPTION 1792 "The collection of objects which are used to represent 1793 physical system components, for which a single agent 1794 provides management information." 1795 ::= { entityGroups 1 } 1797 entityLogicalGroup OBJECT-GROUP 1798 OBJECTS { 1799 entLogicalDescr, 1800 entLogicalType, 1801 entLogicalCommunity, 1802 entLogicalTAddress, 1803 entLogicalTDomain 1804 } 1805 STATUS deprecated 1806 DESCRIPTION 1807 "The collection of objects which are used to represent the 1808 list of logical entities for which a single agent provides 1809 management information." 1810 ::= { entityGroups 2 } 1812 entityMappingGroup OBJECT-GROUP 1813 OBJECTS { 1814 entLPPhysicalIndex, 1815 entAliasMappingIdentifier, 1816 entPhysicalChildIndex 1817 } 1818 STATUS current 1819 DESCRIPTION 1820 "The collection of objects which are used to represent the 1821 associations between multiple logical entities, physical 1822 components, interfaces, and port identifiers for which a 1823 single agent provides management information." 1824 ::= { entityGroups 3 } 1826 entityGeneralGroup OBJECT-GROUP 1827 OBJECTS { 1828 entLastChangeTime 1829 } 1830 STATUS current 1831 DESCRIPTION 1832 "The collection of objects which are used to represent 1833 general entity information for which a single agent provides 1834 management information." 1835 ::= { entityGroups 4 } 1837 entityNotificationsGroup NOTIFICATION-GROUP 1838 NOTIFICATIONS { entConfigChange } 1839 STATUS current 1840 DESCRIPTION 1841 "The collection of notifications used to indicate Entity MIB 1842 data consistency and general status information." 1843 ::= { entityGroups 5 } 1845 entityPhysical2Group OBJECT-GROUP 1846 OBJECTS { 1847 entPhysicalHardwareRev, 1848 entPhysicalFirmwareRev, 1849 entPhysicalSoftwareRev, 1850 entPhysicalSerialNum, 1851 entPhysicalMfgName, 1852 entPhysicalModelName, 1853 entPhysicalAlias, 1854 entPhysicalAssetID, 1855 entPhysicalIsFRU 1856 } 1858 STATUS current 1859 DESCRIPTION 1860 "The collection of objects which are used to represent 1861 physical system components, for which a single agent 1862 provides management information. This group augments the 1863 objects contained in the entityPhysicalGroup." 1864 ::= { entityGroups 6 } 1866 entityLogical2Group OBJECT-GROUP 1867 OBJECTS { 1868 entLogicalDescr, 1869 entLogicalType, 1870 entLogicalTAddress, 1871 entLogicalTDomain, 1872 entLogicalContextEngineID, 1873 entLogicalContextName 1874 } 1875 STATUS current 1876 DESCRIPTION 1877 "The collection of objects which are used to represent the 1878 list of logical entities for which a single SNMP entity 1879 provides management information." 1880 ::= { entityGroups 7 } 1882 END 1883 7. Usage Examples 1885 The following sections iterate the instance values for two example 1886 networking devices. These examples are kept simple to make them more 1887 understandable. Auxiliary components, such as fans, sensors, empty 1888 slots, and sub-modules are not shown, but might be modeled in real 1889 implementations. 1891 7.1. Router/Bridge 1893 A router containing two slots. Each slot contains a 3 port 1894 router/bridge module. Each port is represented in the ifTable. There 1895 are two logical instances of OSPF running and two logical bridges: 1897 Physical entities -- entPhysicalTable: 1898 1 Field-replaceable physical chassis: 1899 entPhysicalDescr.1 == 'Acme Chassis Model 100' 1900 entPhysicalVendorType.1 == acmeProducts.chassisTypes.1 1901 entPhysicalContainedIn.1 == 0 1902 entPhysicalClass.1 == chassis(3) 1903 entPhysicalParentRelPos.1 == 0 1904 entPhysicalName.1 == '100-A' 1905 entPhysicalHardwareRev.1 == 'A(1.00.02)' 1906 entPhysicalSoftwareRev.1 == '' 1907 entPhysicalFirmwareRev.1 == '' 1908 entPhysicalSerialNum.1 == 'C100076544' 1909 entPhysicalMfgName.1 == 'Acme' 1910 entPhysicalModelName.1 == '100' 1911 entPhysicalAlias.1 == 'cl-SJ17-3-006:rack1:rtr-U3' 1912 entPhysicalAssetID.1 == '0007372293' 1913 entPhysicalIsFRU.1 == true(1) 1915 2 slots within the chassis: 1916 entPhysicalDescr.2 == 'Acme Chassis Slot Type AA' 1917 entPhysicalVendorType.2 == acmeProducts.slotTypes.1 1918 entPhysicalContainedIn.2 == 1 1919 entPhysicalClass.2 == container(5) 1920 entPhysicalParentRelPos.2 == 1 1921 entPhysicalName.2 == 'S1' 1922 entPhysicalHardwareRev.2 == 'B(1.00.01)' 1923 entPhysicalSoftwareRev.2 == '' 1924 entPhysicalFirmwareRev.2 == '' 1925 entPhysicalSerialNum.2 == '' 1926 entPhysicalMfgName.2 == 'Acme' 1927 entPhysicalModelName.2 == 'AA' 1928 entPhysicalAlias.2 == '' 1929 entPhysicalAssetID.2 == '' 1930 entPhysicalIsFRU.2 == false(2) 1932 entPhysicalDescr.3 == 'Acme Chassis Slot Type AA' 1933 entPhysicalVendorType.3 = acmeProducts.slotTypes.1 1934 entPhysicalContainedIn.3 == 1 1935 entPhysicalClass.3 == container(5) 1936 entPhysicalParentRelPos.3 == 2 1937 entPhysicalName.3 == 'S2' 1938 entPhysicalHardwareRev.3 == '1.00.07' 1939 entPhysicalSoftwareRev.3 == '' 1940 entPhysicalFirmwareRev.3 == '' 1941 entPhysicalSerialNum.3 == '' 1942 entPhysicalMfgName.3 == 'Acme' 1943 entPhysicalModelName.3 == 'AA' 1944 entPhysicalAlias.3 == '' 1945 entPhysicalAssetID.3 == '' 1946 entPhysicalIsFRU.3 == false(2) 1948 2 Field-replaceable modules: 1949 Slot 1 contains a module with 3 ports: 1950 entPhysicalDescr.4 == 'Acme Router-100' 1951 entPhysicalVendorType.4 == acmeProducts.moduleTypes.14 1952 entPhysicalContainedIn.4 == 2 1953 entPhysicalClass.4 == module(9) 1954 entPhysicalParentRelPos.4 == 1 1955 entPhysicalName.4 == 'M1' 1956 entPhysicalHardwareRev.4 == '1.00.07' 1957 entPhysicalSoftwareRev.4 == '1.4.1' 1958 entPhysicalFirmwareRev.4 == 'A(1.1)' 1959 entPhysicalSerialNum.4 == 'C100087363' 1960 entPhysicalMfgName.4 == 'Acme' 1961 entPhysicalModelName.4 == 'R100-FE' 1962 entPhysicalAlias.4 == 'rtr-U3:m1:SJ17-3-eng' 1963 entPhysicalAssetID.4 == '0007372462' 1964 entPhysicalIsFRU.4 == true(1) 1966 entPhysicalDescr.5 == 'Acme Ethernet-100 Port' 1967 entPhysicalVendorType.5 == acmeProducts.portTypes.2 1968 entPhysicalContainedIn.5 == 4 1969 entPhysicalClass.5 == port(10) 1970 entPhysicalParentRelPos.5 == 1 1971 entPhysicalName.5 == 'P1' 1972 entPhysicalHardwareRev.5 == 'G(1.02)' 1973 entPhysicalSoftwareRev.5 == '' 1974 entPhysicalFirmwareRev.5 == '1.1' 1975 entPhysicalSerialNum.5 == '' 1976 entPhysicalMfgName.5 == 'Acme' 1977 entPhysicalModelName.5 == 'FE-100' 1978 entPhysicalAlias.5 == '' 1979 entPhysicalAssetID.5 == '' 1980 entPhysicalIsFRU.5 == false(2) 1982 entPhysicalDescr.6 == 'Acme Ethernet-100 Port' 1983 entPhysicalVendorType.6 == acmeProducts.portTypes.2 1984 entPhysicalContainedIn.6 == 4 1985 entPhysicalClass.6 == port(10) 1986 entPhysicalParentRelPos.6 == 2 1987 entPhysicalName.6 == 'P2' 1988 entPhysicalHardwareRev.6 == 'G(1.02)' 1989 entPhysicalSoftwareRev.6 == '' 1990 entPhysicalFirmwareRev.6 == '1.1' 1991 entPhysicalSerialNum.6 == '' 1992 entPhysicalMfgName.6 == 'Acme' 1993 entPhysicalModelName.6 == 'FE-100' 1994 entPhysicalAlias.6 == '' 1995 entPhysicalAssetID.6 == '' 1996 entPhysicalIsFRU.6 == false(2) 1998 entPhysicalDescr.7 == 'Acme Router-100 FDDI-Port' 1999 entPhysicalVendorType.7 == acmeProducts.portTypes.3 2000 entPhysicalContainedIn.7 == 4 2001 entPhysicalClass.7 == port(10) 2002 entPhysicalParentRelPos.7 == 3 2003 entPhysicalName.7 == 'P3' 2004 entPhysicalHardwareRev.7 == 'B(1.03)' 2005 entPhysicalSoftwareRev.7 == '2.5.1' 2006 entPhysicalFirmwareRev.7 == '2.5F' 2007 entPhysicalSerialNum.7 == '' 2008 entPhysicalMfgName.7 == 'Acme' 2009 entPhysicalModelName.7 == 'FDDI-100' 2010 entPhysicalAlias.7 == '' 2011 entPhysicalAssetID.7 == '' 2012 entPhysicalIsFRU.7 == false(2) 2014 Slot 2 contains another 3-port module: 2015 entPhysicalDescr.8 == 'Acme Router-100 Comm Module' 2016 entPhysicalVendorType.8 == acmeProducts.moduleTypes.15 2017 entPhysicalContainedIn.8 == 3 2018 entPhysicalClass.8 == module(9) 2019 entPhysicalParentRelPos.8 == 1 2020 entPhysicalName.8 == 'M2' 2021 entPhysicalHardwareRev.8 == '2.01.00' 2022 entPhysicalSoftwareRev.8 == '3.0.7' 2023 entPhysicalFirmwareRev.8 == 'A(1.2)' 2024 entPhysicalSerialNum.8 == 'C100098732' 2025 entPhysicalMfgName.8 == 'Acme' 2026 entPhysicalModelName.8 == 'C100' 2027 entPhysicalAlias.8 == 'rtr-U3:m2:SJ17-2-eng' 2028 entPhysicalAssetID.8 == '0007373982' 2029 entPhysicalIsFRU.8 == true(1) 2031 entPhysicalDescr.9 == 'Acme Fddi-100 Port' 2032 entPhysicalVendorType.9 == acmeProducts.portTypes.5 2033 entPhysicalContainedIn.9 == 8 2034 entPhysicalClass.9 == port(10) 2035 entPhysicalParentRelPos.9 == 1 2036 entPhysicalName.9 == 'FDDI Primary' 2037 entPhysicalHardwareRev.9 == 'CC(1.07)' 2038 entPhysicalSoftwareRev.9 == '2.0.34' 2039 entPhysicalFirmwareRev.9 == '1.1' 2040 entPhysicalSerialNum.9 == '' 2041 entPhysicalMfgName.9 == 'Acme' 2042 entPhysicalModelName.9 == 'FDDI-100' 2043 entPhysicalAlias.9 == '' 2044 entPhysicalAssetID.9 == '' 2045 entPhysicalIsFRU.9 == false(2) 2047 entPhysicalDescr.10 == 'Acme Ethernet-100 Port' 2048 entPhysicalVendorType.10 == acmeProducts.portTypes.2 2049 entPhysicalContainedIn.10 == 8 2050 entPhysicalClass.10 == port(10) 2051 entPhysicalParentRelPos.10 == 2 2052 entPhysicalName.10 == 'Ethernet A' 2053 entPhysicalHardwareRev.10 == 'G(1.04)' 2054 entPhysicalSoftwareRev.10 == '' 2055 entPhysicalFirmwareRev.10 == '1.3' 2056 entPhysicalSerialNum.10 == '' 2057 entPhysicalMfgName.10 == 'Acme' 2058 entPhysicalModelName.10 == 'FE-100' 2059 entPhysicalAlias.10 == '' 2060 entPhysicalAssetID.10 == '' 2061 entPhysicalIsFRU.10 == false(2) 2062 entPhysicalDescr.11 == 'Acme Ethernet-100 Port' 2063 entPhysicalVendorType.11 == acmeProducts.portTypes.2 2064 entPhysicalContainedIn.11 == 8 2065 entPhysicalClass.11 == port(10) 2066 entPhysicalParentRelPos.11 == 3 2067 entPhysicalName.11 == 'Ethernet B' 2068 entPhysicalHardwareRev.11 == 'G(1.04)' 2069 entPhysicalSoftwareRev.11 == '' 2070 entPhysicalFirmwareRev.11 == '1.3' 2071 entPhysicalSerialNum.11 == '' 2072 entPhysicalMfgName.11 == 'Acme' 2073 entPhysicalModelName.11 == 'FE-100' 2074 entPhysicalAlias.11 == '' 2075 entPhysicalAssetID.11 == '' 2076 entPhysicalIsFRU.11 == false(2) 2078 Logical entities -- entLogicalTable; no SNMPv3 support 2079 2 OSPF instances: 2080 entLogicalDescr.1 == 'Acme OSPF v1.1' 2081 entLogicalType.1 == ospf 2082 entLogicalCommunity.1 == 'public-ospf1' 2083 entLogicalTAddress.1 == 124.125.126.127:161 2084 entLogicalTDomain.1 == snmpUDPDomain 2085 entLogicalContextEngineID.1 == '' 2086 entLogicalContextName.1 == '' 2088 entLogicalDescr.2 == 'Acme OSPF v1.1' 2089 entLogicalType.2 == ospf 2090 entLogicalCommunity.2 == 'public-ospf2' 2091 entLogicalTAddress.2 == 124.125.126.127:161 2092 entLogicalTDomain.2 == snmpUDPDomain 2093 entLogicalContextEngineID.2 == '' 2094 entLogicalContextName.2 == '' 2096 2 logical bridges: 2097 entLogicalDescr.3 == 'Acme Bridge v2.1.1' 2098 entLogicalType.3 == dot1dBridge 2099 entLogicalCommunity.3 == 'public-bridge1' 2100 entLogicalTAddress.3 == 124.125.126.127:161 2101 entLogicalTDomain.3 == snmpUDPDomain 2102 entLogicalContextEngineID.3 == '' 2103 entLogicalContextName.3 == '' 2105 entLogicalDescr.4 == 'Acme Bridge v2.1.1' 2106 entLogicalType.4 == dot1dBridge 2107 entLogicalCommunity.4 == 'public-bridge2' 2108 entLogicalTAddress.4 == 124.125.126.127:161 2109 entLogicalTDomain.4 == snmpUDPDomain 2110 entLogicalContextEngineID.4 == '' 2111 entLogicalContextName.4 == '' 2113 Logical to Physical Mappings: 2114 1st OSPF instance: uses module 1-port 1 2115 entLPPhysicalIndex.1.5 == 5 2117 2nd OSPF instance: uses module 2-port 1 2118 entLPPhysicalIndex.2.9 == 9 2120 1st bridge group: uses module 1, all ports 2122 [ed. -- Note that these mappings are included in the table since 2123 another logical entity (1st OSPF) utilizes one of the 2124 ports. If this were not the case, then a single mapping 2125 to the module (e.g., entLPPhysicalIndex.3.4) would be 2126 present instead. ] 2127 entLPPhysicalIndex.3.5 == 5 2128 entLPPhysicalIndex.3.6 == 6 2129 entLPPhysicalIndex.3.7 == 7 2131 2nd bridge group: uses module 2, all ports 2132 entLPPhysicalIndex.4.9 == 9 2133 entLPPhysicalIndex.4.10 == 10 2134 entLPPhysicalIndex.4.11 == 11 2136 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 2137 Example 1: ifIndex values are global to all logical entities 2138 entAliasMappingIdentifier.5.0 == ifIndex.1 2139 entAliasMappingIdentifier.6.0 == ifIndex.2 2140 entAliasMappingIdentifier.7.0 == ifIndex.3 2141 entAliasMappingIdentifier.9.0 == ifIndex.4 2142 entAliasMappingIdentifier.10.0 == ifIndex.5 2143 entAliasMappingIdentifier.11.0 == ifIndex.6 2145 Example 2: ifIndex values are not shared by all logical entities 2146 entAliasMappingIdentifier.5.0 == ifIndex.1 2147 entAliasMappingIdentifier.5.3 == ifIndex.101 2148 entAliasMappingIdentifier.6.0 == ifIndex.2 2149 entAliasMappingIdentifier.6.3 == ifIndex.102 2150 entAliasMappingIdentifier.7.0 == ifIndex.3 2151 entAliasMappingIdentifier.7.3 == ifIndex.103 2152 entAliasMappingIdentifier.9.0 == ifIndex.4 2153 entAliasMappingIdentifier.9.3 == ifIndex.204 2154 entAliasMappingIdentifier.10.0 == ifIndex.5 2155 entAliasMappingIdentifier.10.3 == ifIndex.205 2156 entAliasMappingIdentifier.11.0 == ifIndex.6 2157 entAliasMappingIdentifier.11.3 == ifIndex.206 2159 Physical Containment Tree -- entPhysicalContainsTable 2160 chassis has two containers: 2161 entPhysicalChildIndex.1.2 == 2 2162 entPhysicalChildIndex.1.3 == 3 2164 container 1 has a module: 2165 entPhysicalChildIndex.2.4 == 4 2167 container 2 has a module: 2168 entPhysicalChildIndex.3.8 == 8 2170 module 1 has 3 ports: 2171 entPhysicalChildIndex.4.5 == 5 2172 entPhysicalChildIndex.4.6 == 6 2173 entPhysicalChildIndex.4.7 == 7 2175 module 2 has 3 ports: 2176 entPhysicalChildIndex.8.9 == 9 2177 entPhysicalChildIndex.8.10 == 10 2178 entPhysicalChildIndex.1.11 == 11 2180 7.2. Repeaters 2182 A 3-slot Hub with 2 backplane ethernet segments. Slot three is empty, 2183 and the remaining slots contain ethernet repeater modules. 2185 Note that this example assumes an older Repeater MIB implementation, 2186 (RFC 1516 [RFC1516]) rather than the new Repeater MIB (RFC 2108 2187 [RFC2108]). The new version contains an object called 'rptrPortRptrId', 2188 which should be used to identify repeater port groupings, rather than 2189 with community strings or contexts. 2191 Physical entities -- entPhysicalTable: 2192 1 Field-replaceable physical chassis: 2193 entPhysicalDescr.1 == 'Acme Chassis Model 110' 2194 entPhysicalVendorType.1 == acmeProducts.chassisTypes.2 2195 entPhysicalContainedIn.1 == 0 2196 entPhysicalClass.1 == chassis(3) 2197 entPhysicalParentRelPos.1 == 0 2198 entPhysicalName.1 == '110-B' 2199 entPhysicalHardwareRev.1 == 'A(1.02.00)' 2200 entPhysicalSoftwareRev.1 == '' 2201 entPhysicalFirmwareRev.1 == '' 2202 entPhysicalSerialNum.1 == 'C100079294' 2203 entPhysicalMfgName.1 == 'Acme' 2204 entPhysicalModelName.1 == '110' 2205 entPhysicalAlias.1 == 'bldg09:floor1:rptr18:0067eea0229f' 2206 entPhysicalAssetID.1 == '0007386327' 2207 entPhysicalIsFRU.1 == true(1) 2209 2 Chassis Ethernet Backplanes: 2210 entPhysicalDescr.2 == 'Acme Ethernet Backplane Type A' 2211 entPhysicalVendorType.2 == acmeProducts.backplaneTypes.1 2212 entPhysicalContainedIn.2 == 1 2213 entPhysicalClass.2 == backplane(4) 2214 entPhysicalParentRelPos.2 == 1 2215 entPhysicalName.2 == 'B1' 2216 entPhysicalHardwareRev.2 == 'A(2.04.01)' 2217 entPhysicalSoftwareRev.2 == '' 2218 entPhysicalFirmwareRev.2 == '' 2219 entPhysicalSerialNum.2 == '' 2220 entPhysicalMfgName.2 == 'Acme' 2221 entPhysicalModelName.2 == 'BK-A' 2222 entPhysicalAlias.2 == '' 2223 entPhysicalAssetID.2 == '' 2224 entPhysicalIsFRU.2 == false(2) 2226 entPhysicalDescr.3 == 'Acme Ethernet Backplane Type A' 2227 entPhysicalVendorType.3 == acmeProducts.backplaneTypes.1 2228 entPhysicalContainedIn.3 == 1 2229 entPhysicalClass.3 == backplane(4) 2230 entPhysicalParentRelPos.3 == 2 2231 entPhysicalName.3 == 'B2' 2232 entPhysicalHardwareRev.3 == 'A(2.04.01)' 2233 entPhysicalSoftwareRev.3 == '' 2234 entPhysicalFirmwareRev.3 == '' 2235 entPhysicalSerialNum.3 == '' 2236 entPhysicalMfgName.3 == 'Acme' 2237 entPhysicalModelName.3 == 'BK-A' 2238 entPhysicalAlias.3 == '' 2239 entPhysicalAssetID.3 == '' 2240 entPhysicalIsFRU.3 == false(2) 2242 3 slots within the chassis: 2243 entPhysicalDescr.4 == 'Acme Hub Slot Type RB' 2244 entPhysicalVendorType.4 == acmeProducts.slotTypes.5 2245 entPhysicalContainedIn.4 == 1 2246 entPhysicalClass.4 == container(5) 2247 entPhysicalParentRelPos.4 == 1 2248 entPhysicalName.4 == 'Slot 1' 2249 entPhysicalHardwareRev.4 == 'B(1.00.03)' 2250 entPhysicalSoftwareRev.4 == '' 2251 entPhysicalFirmwareRev.4 == '' 2252 entPhysicalSerialNum.4 == '' 2253 entPhysicalMfgName.4 == 'Acme' 2254 entPhysicalModelName.4 == 'RB' 2255 entPhysicalAlias.4 == '' 2256 entPhysicalAssetID.4 == '' 2257 entPhysicalIsFRU.4 == false(2) 2259 entPhysicalDescr.5 == 'Acme Hub Slot Type RB' 2260 entPhysicalVendorType.5 == acmeProducts.slotTypes.5 2261 entPhysicalContainedIn.5 == 1 2262 entPhysicalClass.5 == container(5) 2263 entPhysicalParentRelPos.5 == 2 2264 entPhysicalName.5 == 'Slot 2' 2265 entPhysicalHardwareRev.5 == 'B(1.00.03)' 2266 entPhysicalSoftwareRev.5 == '' 2267 entPhysicalFirmwareRev.5 == '' 2268 entPhysicalSerialNum.5 == '' 2269 entPhysicalMfgName.5 == 'Acme' 2270 entPhysicalModelName.5 == 'RB' 2271 entPhysicalAlias.5 == '' 2272 entPhysicalAssetID.5 == '' 2273 entPhysicalIsFRU.5 == false(2) 2275 entPhysicalDescr.6 == 'Acme Hub Slot Type RB' 2276 entPhysicalVendorType.6 == acmeProducts.slotTypes.5 2277 entPhysicalContainedIn.6 == 1 2278 entPhysicalClass.6 == container(5) 2279 entPhysicalParentRelPos.6 == 3 2280 entPhysicalName.6 == 'Slot 3' 2281 entPhysicalHardwareRev.6 == 'B(1.00.03)' 2282 entPhysicalSoftwareRev.6 == '' 2283 entPhysicalFirmwareRev.6 == '' 2284 entPhysicalSerialNum.6 == '' 2285 entPhysicalMfgName.6 == 'Acme' 2286 entPhysicalModelName.6 == 'RB' 2287 entPhysicalAlias.6 == '' 2288 entPhysicalAssetID.6 == '' 2289 entPhysicalIsFRU.6 == false(2) 2291 Slot 1 contains a plug-in module with 4 10-BaseT ports: 2292 entPhysicalDescr.7 == 'Acme 10Base-T Module 114' 2293 entPhysicalVendorType.7 == acmeProducts.moduleTypes.32 2294 entPhysicalContainedIn.7 == 4 2295 entPhysicalClass.7 == module(9) 2296 entPhysicalParentRelPos.7 == 1 2297 entPhysicalName.7 == 'M1' 2298 entPhysicalHardwareRev.7 == 'A(1.02.01)' 2299 entPhysicalSoftwareRev.7 == '1.7.2' 2300 entPhysicalFirmwareRev.7 == 'A(1.5)' 2301 entPhysicalSerialNum.7 == 'C100096244' 2302 entPhysicalMfgName.7 == 'Acme' 2303 entPhysicalModelName.7 = '114' 2304 entPhysicalAlias.7 == 'bldg09:floor1:eng' 2305 entPhysicalAssetID.7 == '0007962951' 2306 entPhysicalIsFRU.7 == true(1) 2308 entPhysicalDescr.8 == 'Acme 10Base-T Port RB' 2309 entPhysicalVendorType.8 == acmeProducts.portTypes.10 2310 entPhysicalContainedIn.8 == 7 2311 entPhysicalClass.8 == port(10) 2312 entPhysicalParentRelPos.8 == 1 2313 entPhysicalName.8 == 'Ethernet-A' 2314 entPhysicalHardwareRev.8 == 'A(1.04F)' 2315 entPhysicalSoftwareRev.8 == '' 2316 entPhysicalFirmwareRev.8 == '1.4' 2317 entPhysicalSerialNum.8 == '' 2318 entPhysicalMfgName.8 == 'Acme' 2319 entPhysicalModelName.8 == 'RB' 2320 entPhysicalAlias.8 == '' 2321 entPhysicalAssetID.8 == '' 2322 entPhysicalIsFRU.8 == false(2) 2324 entPhysicalDescr.9 == 'Acme 10Base-T Port RB' 2325 entPhysicalVendorType.9 == acmeProducts.portTypes.10 2326 entPhysicalContainedIn.9 == 7 2327 entPhysicalClass.9 == port(10) 2328 entPhysicalParentRelPos.9 == 2 2329 entPhysicalName.9 == 'Ethernet-B' 2330 entPhysicalHardwareRev.9 == 'A(1.04F)' 2331 entPhysicalSoftwareRev.9 == '' 2332 entPhysicalFirmwareRev.9 == '1.4' 2333 entPhysicalSerialNum.9 == '' 2334 entPhysicalMfgName.9 == 'Acme' 2335 entPhysicalModelName.9 = 'RB' 2336 entPhysicalAlias.9 == '' 2337 entPhysicalAssetID.9 == '' 2338 entPhysicalIsFRU.9 == false(2) 2340 entPhysicalDescr.10 == 'Acme 10Base-T Port RB' 2341 entPhysicalVendorType.10 == acmeProducts.portTypes.10 2342 entPhysicalContainedIn.10 == 7 2343 entPhysicalClass.10 == port(10) 2344 entPhysicalParentRelPos.10 == 3 2345 entPhysicalName.10 == 'Ethernet-C' 2346 entPhysicalHardwareRev.10 == 'B(1.02.07)' 2347 entPhysicalSoftwareRev.10 == '' 2348 entPhysicalFirmwareRev.10 == '1.4' 2349 entPhysicalSerialNum.10 == '' 2350 entPhysicalMfgName.10 == 'Acme' 2351 entPhysicalModelName.10 == 'RB' 2352 entPhysicalAlias.10 == '' 2353 entPhysicalAssetID.10 == '' 2354 entPhysicalIsFRU.10 == false(2) 2356 entPhysicalDescr.11 == 'Acme 10Base-T Port RB' 2357 entPhysicalVendorType.11 == acmeProducts.portTypes.10 2358 entPhysicalContainedIn.11 == 7 2359 entPhysicalClass.11 == port(10) 2360 entPhysicalParentRelPos.11 == 4 2361 entPhysicalName.11 == 'Ethernet-D' 2362 entPhysicalHardwareRev.11 == 'B(1.02.07)' 2363 entPhysicalSoftwareRev.11 == '' 2364 entPhysicalFirmwareRev.11 == '1.4' 2365 entPhysicalSerialNum.11 == '' 2366 entPhysicalMfgName.11 == 'Acme' 2367 entPhysicalModelName.11 == 'RB' 2368 entPhysicalAlias.11 == '' 2369 entPhysicalAssetID.11 == '' 2370 entPhysicalIsFRU.11 == false(2) 2372 Slot 2 contains another ethernet module with 2 ports. 2373 entPhysicalDescr.12 == 'Acme 10Base-T Module Model 4' 2374 entPhysicalVendorType.12 == acmeProducts.moduleTypes.30 2375 entPhysicalContainedIn.12 = 5 2376 entPhysicalClass.12 == module(9) 2377 entPhysicalParentRelPos.12 == 1 2378 entPhysicalName.12 == 'M2' 2379 entPhysicalHardwareRev.12 == 'A(1.01.07)' 2380 entPhysicalSoftwareRev.12 == '1.8.4' 2381 entPhysicalFirmwareRev.12 == 'A(1.8)' 2382 entPhysicalSerialNum.12 == 'C100102384' 2383 entPhysicalMfgName.12 == 'Acme' 2384 entPhysicalModelName.12 == '4' 2385 entPhysicalAlias.12 == 'bldg09:floor1:devtest' 2386 entPhysicalAssetID.12 == '0007968462' 2387 entPhysicalIsFRU.12 == true(1) 2389 entPhysicalDescr.13 == 'Acme 802.3 AUI Port' 2390 entPhysicalVendorType.13 == acmeProducts.portTypes.11 2391 entPhysicalContainedIn.13 == 12 2392 entPhysicalClass.13 == port(10) 2393 entPhysicalParentRelPos.13 == 1 2394 entPhysicalName.13 == 'AUI' 2395 entPhysicalHardwareRev.13 == 'A(1.06F)' 2396 entPhysicalSoftwareRev.13 == '' 2397 entPhysicalFirmwareRev.13 == '1.5' 2398 entPhysicalSerialNum.13 == '' 2399 entPhysicalMfgName.13 == 'Acme' 2400 entPhysicalModelName.13 == '' 2401 entPhysicalAlias.13 == '' 2402 entPhysicalAssetID.13 == '' 2403 entPhysicalIsFRU.13 == false(2) 2405 entPhysicalDescr.14 == 'Acme 10Base-T Port RD' 2406 entPhysicalVendorType.14 == acmeProducts.portTypes.14 2407 entPhysicalContainedIn.14 == 12 2408 entPhysicalClass.14 == port(10) 2409 entPhysicalParentRelPos.14 == 2 2410 entPhysicalName.14 == 'E2' 2411 entPhysicalHardwareRev.14 == 'B(1.01.02)' 2412 entPhysicalSoftwareRev.14 == '' 2413 entPhysicalFirmwareRev.14 == '2.1' 2414 entPhysicalSerialNum.14 == '' 2415 entPhysicalMfgName.14 == 'Acme' 2416 entPhysicalModelName.14 == '' 2417 entPhysicalAlias.14 == '' 2418 entPhysicalAssetID.14 == '' 2419 entPhysicalIsFRU.14 == false(2) 2421 Logical entities -- entLogicalTable; with SNMPv3 support 2422 Repeater 1--comprised of any ports attached to backplane 1 2423 entLogicalDescr.1 == 'Acme repeater v3.1' 2424 entLogicalType.1 == snmpDot3RptrMgt 2425 entLogicalCommunity.1 'public-repeater1' 2426 entLogicalTAddress.1 == 124.125.126.127:161 2427 entLogicalTDomain.1 == snmpUDPDomain 2428 entLogicalContextEngineID.1 == '80000777017c7d7e7f'H 2429 entLogicalContextName.1 == 'repeater1' 2431 Repeater 2--comprised of any ports attached to backplane 2: 2432 entLogicalDescr.2 == 'Acme repeater v3.1' 2433 entLogicalType.2 == snmpDot3RptrMgt 2434 entLogicalCommunity.2 == 'public-repeater2' 2435 entLogicalTAddress.2 == 124.125.126.127:161 2436 entLogicalTDomain.2 == snmpUDPDomain 2437 entLogicalContextEngineID.2 == '80000777017c7d7e7f'H 2438 entLogicalContextName.2 == 'repeater2' 2440 Logical to Physical Mappings -- entLPMappingTable: 2442 repeater1 uses backplane 1, slot 1-ports 1 & 2, slot 2-port 1 2443 [ed. -- Note that a mapping to the module is not included, 2444 since in this example represents a port-switchable hub. 2445 Even though all ports on the module could belong to the 2446 same repeater as a matter of configuration, the LP port 2447 mappings should not be replaced dynamically with a single 2448 mapping for the module (e.g., entLPPhysicalIndex.1.7). 2449 If all ports on the module shared a single backplane connection, 2450 then a single mapping for the module would be more appropriate. ] 2452 entLPPhysicalIndex.1.2 == 2 2453 entLPPhysicalIndex.1.8 == 8 2454 entLPPhysicalIndex.1.9 == 9 2455 entLPPhysicalIndex.1.13 == 13 2457 repeater2 uses backplane 2, slot 1-ports 3 & 4, slot 2-port 2 2458 entLPPhysicalIndex.2.3 == 3 2459 entLPPhysicalIndex.2.10 == 10 2460 entLPPhysicalIndex.2.11 == 11 2461 entLPPhysicalIndex.2.14 == 14 2463 Physical to Logical to MIB Alias Mappings -- entAliasMappingTable: 2464 Repeater Port Identifier values are shared by both repeaters: 2465 entAliasMappingIdentifier.8.0 == rptrPortGroupIndex.1.1 2466 entAliasMappingIdentifier.9.0 == rptrPortGroupIndex.1.2 2467 entAliasMappingIdentifier.10.0 == rptrPortGroupIndex.1.3 2468 entAliasMappingIdentifier.11.0 == rptrPortGroupIndex.1.4 2469 entAliasMappingIdentifier.13.0 == rptrPortGroupIndex.2.1 2470 entAliasMappingIdentifier.14.0 == rptrPortGroupIndex.2.2 2472 Physical Containment Tree -- entPhysicalContainsTable 2473 chassis has two backplanes and three containers: 2474 entPhysicalChildIndex.1.2 == 2 2475 entPhysicalChildIndex.1.3 == 3 2476 entPhysicalChildIndex.1.4 == 4 2477 entPhysicalChildIndex.1.5 == 5 2478 entPhysicalChildIndex.1.6 == 6 2480 container 1 has a module: 2481 entPhysicalChildIndex.4.7 == 7 2483 container 2 has a module 2484 entPhysicalChildIndex.5.12 == 12 2485 [ed. - in this example, container 3 is empty.] 2487 module 1 has 4 ports: 2488 entPhysicalChildIndex.7.8 == 8 2489 entPhysicalChildIndex.7.9 == 9 2490 entPhysicalChildIndex.7.10 == 10 2491 entPhysicalChildIndex.7.11 == 11 2493 module 2 has 2 ports: 2494 entPhysicalChildIndex.12.13 == 13 2495 entPhysicalChildIndex.12.14 == 14 2497 8. Intellectual Property 2499 The IETF takes no position regarding the validity or scope of any 2500 intellectual property or other rights that might be claimed to pertain 2501 to the implementation or use of the technology described in this 2502 document or the extent to which any license under such rights might or 2503 might not be available; neither does it represent that it has made any 2504 effort to identify any such rights. Information on the IETF's 2505 procedures with respect to rights in standards-track and standards- 2506 related documentation can be found in BCP-11. Copies of claims of 2507 rights made available for publication and any assurances of licenses to 2508 be made available, or the result of an attempt made to obtain a general 2509 license or permission for the use of such proprietary rights by 2510 implementors or users of this specification can be obtained from the 2511 IETF Secretariat. 2513 The IETF invites any interested party to bring to its attention any 2514 copyrights, patents or patent applications, or other proprietary rights 2515 which may cover technology that may be required to practice this 2516 standard. Please address the information to the IETF Executive 2517 Director. 2519 9. Acknowledgements 2521 This memo has been produced by the IETF's Entity MIB working group. 2523 10. References 2525 [RFC1155] 2526 Rose, M., and K. McCloghrie, "Structure and Identification of 2527 Management Information for TCP/IP-based Internets", RFC 1155, STD 2528 16, Performance Systems International, Hughes LAN Systems, May 2529 1990. 2531 [RFC1157] 2532 Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 2533 Management Protocol", RFC 1157, STD 15, SNMP Research, Performance 2534 Systems International, Performance Systems International, MIT 2535 Laboratory for Computer Science, May 1990. 2537 [RFC1212] 2538 Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 2539 STD 16, Performance Systems International, Hughes LAN Systems, 2540 March 1991. 2542 [RFC1215] 2543 M. Rose, "A Convention for Defining Traps for use with the SNMP", 2544 RFC 1215, Performance Systems International, March 1991. 2546 [RFC1493] 2547 Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, 2548 "Definitions of Managed Objects for Bridges", RFC 1493, cisco 2549 Systems, Digital Equipment Corporation, Hughes LAN Systems, Inc., 2550 July, 1993. 2552 [RFC1516] 2553 McMaster, D., and K. McCloghrie, "Definitions of Managed Objects 2554 for IEEE 802.3 Repeater Devices", RFC 1516, SynOptics 2555 Communications, Inc., Hughes LAN Systems, Inc., September, 1993. 2557 [RFC1901] 2558 Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 2559 "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, 2560 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 2561 International Network Services, January 1996. 2563 [RFC1905] 2564 Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 2565 Operations for Version 2 of the Simple Network Management Protocol 2566 (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., 2567 Dover Beach Consulting, Inc., International Network Services, 2568 January 1996. 2570 [RFC1906] 2571 Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 2572 Mappings for Version 2 of the Simple Network Management Protocol 2573 (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., 2574 Dover Beach Consulting, Inc., International Network Services, 2575 January 1996. 2577 [RFC2026] 2578 Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2579 2026, Harvard University, October, 1996. 2581 [RFC2037] 2582 McCloghrie, K., and A. Bierman, "Entity MIB using SMIv2", RFC 2037, 2583 Cisco Systems, October 1996. 2585 [RFC2108] 2586 de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, 2587 "Definitions of Managed Objects for IEEE 802.3 Repeater Devices 2588 using SMIv2", RFC 2108, 3Com Corporation, Madge Networks (Israel) 2589 Ltd., Coloma Communications, Cisco Systems Inc., February, 1997. 2591 [RFC2233] 2592 McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB Using 2593 SMIv2", RFC 2233, Cisco Systems, FTP Software, November, 1997. 2595 [RFC2570] 2596 Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to 2597 Version 3 of the Internet-standard Network Management Framework", 2598 RFC 2570, SNMP Research, Inc., TIS Labs at Network Associates, 2599 Inc., Ericsson, Cisco Systems, April 1999. 2601 [RFC2571] 2602 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 2603 Describing SNMP Management Frameworks", RFC 2571, Cabletron 2604 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 2605 1999. 2607 [RFC2572] 2608 Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 2609 Processing and Dispatching for the Simple Network Management 2610 Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems, 2611 Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999. 2613 [RFC2573] 2614 Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2615 2573, SNMP Research, Inc., Secure Computing Corporation, Cisco 2616 Systems, April 1999. 2618 [RFC2574] 2619 Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 2620 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2621 2574, IBM T. J. Watson Research, April 1999. 2623 [RFC2575] 2624 Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 2625 Control Model (VACM) for the Simple Network Management Protocol 2626 (SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc., 2627 Cisco Systems, Inc., April 1999. 2629 [RFC2578] 2630 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2631 and S. Waldbusser, "Structure of Management Information Version 2 2632 (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU 2633 Braunschweig, SNMP Research, First Virtual Holdings, International 2634 Network Services, April 1999. 2636 [RFC2579] 2637 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2638 and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 2639 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First 2640 Virtual Holdings, International Network Services, April 1999. 2642 [RFC2580] 2643 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2644 and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, 2645 STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, 2646 First Virtual Holdings, International Network Services, April 1999. 2648 11. Security Considerations 2650 There are a number of management objects defined in this MIB that have a 2651 MAX-ACCESS clause of read-write and/or read-create. Such objects may be 2652 considered sensitive or vulnerable in some network environments. The 2653 support for SET operations in a non-secure environment without proper 2654 protection can have a negative effect on network operations. 2656 There are a number of managed objects in this MIB that may contain 2657 sensitive information. These are: 2659 entPhysicalDescr 2660 entPhysicalVendorType 2661 entPhysicalHardwareRev 2662 entPhysicalFirmwareRev 2663 entPhysicalSoftwareRev 2664 entPhysicalSerialNum 2665 entPhysicalMfgName 2666 entPhysicalModelName 2668 These objects expose information about the physical entities within a 2669 managed system, which may be used to identify the vendor, model, and 2670 version information of each system component. 2672 entPhysicalAssetID 2674 This object can allow asset identifiers for various system components to 2675 be exposed, in the event this MIB object is actually configured by an 2676 NMS application. 2678 entLogicalDescr 2679 entLogicalType 2681 These objects expose the type of logical entities present in the managed 2682 system. 2684 entLogicalCommunity 2686 This object exposes community names associated with particular logical 2687 entites within the system. 2689 entLogicalTAddress 2690 entLogicalTDomain 2692 These objects expose network addresses that can be used to communicate 2693 with an SNMP agent on behalf of particular logical entities within the 2694 system. 2696 entLogicalContextEngineID 2697 entLogicalContextName 2699 These objects identify the authoritative SNMP engine that contains 2700 information on behalf of particular logical entities within the system. 2702 It is thus important to control even GET access to these objects and 2703 possibly to even encrypt the values of these object when sending them 2704 over the network via SNMP. Not all versions of SNMP provide features 2705 for such a secure environment. 2707 SNMPv1 by itself is not a secure environment. Even if the network 2708 itself is secure (for example by using IPSec), even then, there is no 2709 control as to who on the secure network is allowed to access and GET/SET 2710 (read/change/create/delete) the objects in this MIB. 2712 It is recommended that the implementers consider the security features 2713 as provided by the SNMPv3 framework. Specifically, the use of the User- 2714 based Security Model RFC 2574 [RFC2574] and the View-based Access 2715 Control Model RFC 2575 [RFC2575] is recommended. 2717 It is then a customer/user responsibility to ensure that the SNMP entity 2718 giving access to an instance of this MIB, is properly configured to give 2719 access to the objects only to those principals (users) that have 2720 legitimate rights to indeed GET or SET (change/create/delete) them. 2722 12. Authors' Addresses 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 Andy Bierman 2732 Cisco Systems, Inc. 2733 170 West Tasman Drive 2734 San Jose, CA 95134 USA 2735 Phone: +1 408-527-3711 2736 Email: abierman@cisco.com 2738 13. Full Copyright Statement 2740 Copyright (C) The Internet Society (1999). All Rights Reserved. 2742 This document and translations of it may be copied and furnished to 2743 others, and derivative works that comment on or otherwise explain it or 2744 assist in its implementation may be prepared, copied, published and 2745 distributed, in whole or in part, without restriction of any kind, 2746 provided that the above copyright notice and this paragraph are included 2747 on all such copies and derivative works. However, this document itself 2748 may not be modified in any way, such as by removing the copyright notice 2749 or references to the Internet Society or other Internet organizations, 2750 except as needed for the purpose of developing Internet standards in 2751 which case the procedures for copyrights defined in the Internet 2752 Standards process must be followed, or as required to translate it into 2753 languages other than English. 2755 The limited permissions granted above are perpetual and will not be 2756 revoked by the Internet Society or its successors or assigns. 2758 This document and the information contained herein is provided on an "AS 2759 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 2760 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2761 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2762 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2763 FITNESS FOR A PARTICULAR PURPOSE."