RFC3512 日本語訳
3512 Configuring Networks and Devices with Simple Network ManagementProtocol (SNMP). M. MacFaden, D. Partain, J. Saperia, W. Tackabury. April 2003. (Format: TXT=196529 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. MacFaden
Request for Comments: 3512 Riverstone Networks, Inc.
Category: Informational D. Partain
Ericsson
J. Saperia
JDS Consulting, Inc.
W. Tackabury
Gold Wire Technology, Inc.
April 2003
MacFadenがコメントのために要求するワーキンググループM.をネットワークでつないでください: 3512 リバーストンはInc.カテゴリをネットワークでつなぎます: Inc.W.Tackabury金のワイヤ技術Inc.2003年4月に相談する情報のD.パーテインエリクソンJ.Saperia JDS
Configuring Networks and Devices with
Simple Network Management Protocol (SNMP)
簡単なネットワーク管理プロトコルはネットワークとデバイスを構成します。(SNMP)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document is written for readers interested in the Internet Standard Management Framework and its protocol, the Simple Network Management Protocol (SNMP). In particular, it offers guidance in the effective use of SNMP for configuration management. This information is relevant to vendors that build network elements, management application developers, and those that acquire and deploy this technology in their networks.
このドキュメントはインターネットStandard Management Frameworkとそのプロトコル(Simple Network Managementプロトコル(SNMP))に興味を持っている読者のために書かれています。 特に、それはSNMPの構成管理の有効な使用における指導を提供します。 この情報はネットワーク要素、管理アプリケーション開発者、および彼らのネットワークでこの技術を取得して、配布するものを造るベンダーに関連しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Internet Standard Management Framework. . . . . . . . 3
1.2. Configuration and the Internet Standard Management
Frame-work. . . . . . . . . . . . . . . . . . . . . . . . 4
2. Using SNMP as a Configuration Mechanism. . . . . . . . . . . . 5
2.1. Transactions and SNMP . . . . . . . . . . . . . . . . . . 6
2.2. Practical Requirements for Transactional Control. . . . . 6
2.3. Practices in Configuration--Verification. . . . . . . . . 7
3. Designing a MIB Module . . . . . . . . . . . . . . . . . . . . 9
3.1. MIB Module Design - General Issues. . . . . . . . . . . . 10
3.2. Naming MIB modules and Managed Objects. . . . . . . . . . 11
3.3. Transaction Control And State Tracking. . . . . . . . . . 12
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 インターネットの標準の管理フレームワーク。 . . . . . . . 3 1.2. 構成とインターネットの標準の管理フレーム構造。 . . . . . . . . . . . . . . . . . . . . . . . 4 2. 構成メカニズムとしてSNMPを使用します。 . . . . . . . . . . . 5 2.1. トランザクションとSNMP. . . . . . . . . . . . . . . . . . 6 2.2。 取引のコントロールのための実際的な要件。 . . . . 6 2.3. 構成--検証における習慣。 . . . . . . . . 7 3. MIBモジュール. . . . . . . . . . . . . . . . . . . . 9 3.1を設計します。 MIBモジュールデザイン--一般答弁。 . . . . . . . . . . . 10 3.2. モジュールとManaged ObjectsとMIBを命名します。 . . . . . . . . . 11 3.3. トランザクションコントロールと州の追跡。 . . . . . . . . . 12
MacFaden, et al. Informational [Page 1] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[1ページ]のRFC3512
3.3.1. Conceptual Table Row Modification Practices. . . . 12
3.3.2. Fate sharing with multiple tables. . . . . . . . . 13
3.3.3. Transaction Control MIB Objects. . . . . . . . . . 14
3.3.4. Creating And Activating New Table Rows . . . . . . 15
3.3.5. Summary Objects and State Tracking . . . . . . . . 15
3.3.6. Optimizing Configuration Data Transfer . . . . . . 18
3.4. More Index Design Issues. . . . . . . . . . . . . . . . . 22
3.4.1. Simple Integer Indexing. . . . . . . . . . . . . . 23
3.4.2. Indexing with Network Addresses. . . . . . . . . . 23
3.5. Conflicting Controls. . . . . . . . . . . . . . . . . . . 24
3.6. Textual Convention Usage. . . . . . . . . . . . . . . . . 25
3.7. Persistent Configuration. . . . . . . . . . . . . . . . . 26
3.8. Configuration Sets and Activation . . . . . . . . . . . . 28
3.8.1. Operational Activation Considerations. . . . . . . 28
3.8.2. RowStatus and Deactivation . . . . . . . . . . . . 30
3.9. SET Operation Latency . . . . . . . . . . . . . . . . . . 31
3.9.1. Subsystem Latency, Persistence Latency,
and Activation Latency . . . . . . . . . . . . . . 33
3.10. Notifications and Error Reporting. . . . . . . . . . . . 33
3.10.1. Identifying Source of Configuration Changes . . . 34
3.10.2. Limiting Unnecessary Transmission of
Notifications . . . . . . . . . . . . . . . . . . 34
3.10.3. Control of Notification Subsystem . . . . . . . . 36
3.11 Application Error Reporting . . . . . . . . . . . . . . . 36
3.12 Designing MIB Modules for Multiple Managers . . . . . . . 37
3.13 Other MIB Module Design Issues. . . . . . . . . . . . . . 39
3.13.1. Octet String Aggregations . . . . . . . . . . . . 39
3.13.2 Supporting multiple instances of a MIB Module. . . 40
3.13.3 Use of Special Optional Clauses. . . . . . . . . . 41
4. Implementing SNMP Configuration Agents . . . . . . . . . . . . 41
4.1. Operational Consistency . . . . . . . . . . . . . . . . . 41
4.2. Handling Multiple Managers. . . . . . . . . . . . . . . . 43
4.3. Specifying Row Modifiability. . . . . . . . . . . . . . . 44
4.4. Implementing Write-only Access Objects. . . . . . . . . . 44
5. Designing Configuration Management Software. . . . . . . . . . 44
5.1. Configuration Application Interactions
with Managed Systems. . . . . . . . . . . . . . . . . . . 45
5.1.1. SET Operations . . . . . . . . . . . . . . . . . . 46
5.1.2. Configuration Transactions . . . . . . . . . . . . 46
5.1.3. Tracking Configuration Changes . . . . . . . . . . 47
5.1.4. Scalability of Data Retrieval. . . . . . . . . . . 48
6. Deployment and Security Issues . . . . . . . . . . . . . . . . 48
6.1. Basic assumptions about Configuration . . . . . . . . . . 48
6.2. Secure Agent Considerations . . . . . . . . . . . . . . . 49
6.3. Authentication Notifications. . . . . . . . . . . . . . . 49
6.4. Sensitive Information Handling. . . . . . . . . . . . . . 50
7. Policy-based Management. . . . . . . . . . . . . . . . . . . . 51
7.1. What Is the Meaning of 'Policy-based' . . . . . . . . . . 51
3.3.1. 概念的なテーブル行変更は練習されます。 . . . 12 3.3.2. 複数のテーブルと共有される運命。 . . . . . . . . 13 3.3.3. トランザクションコントロールMIBは反対します。 . . . . . . . . . 14 3.3.4. 新しいテーブル行. . . . . . 15 3.3.5を作成して、活性化します。 概要オブジェクトと州の追跡. . . . . . . . 15 3.3.6。 構成データ転送. . . . . . 18 3.4を最適化します。 以上はデザイン問題に索引をつけます。 . . . . . . . . . . . . . . . . 22 3.4.1. 簡単な整数インデックス。 . . . . . . . . . . . . . 23 3.4.2. ネットワーク・アドレスで、索引をつけます。 . . . . . . . . . 23 3.5. 闘争は制御されます。 . . . . . . . . . . . . . . . . . . 24 3.6. 原文のコンベンション用法。 . . . . . . . . . . . . . . . . 25 3.7. 永続的な構成。 . . . . . . . . . . . . . . . . 26 3.8. 構成セットと起動. . . . . . . . . . . . 28 3.8.1。 操作上の起動問題。 . . . . . . 28 3.8.2. RowStatusと非活性化. . . . . . . . . . . . 30 3.9。 操作潜在. . . . . . . . . . . . . . . . . . 31 3.9.1を設定してください。 サブシステム潜在、固執潜在、および起動潜在. . . . . . . . . . . . . . 33 3.10。 通知と誤り報告。 . . . . . . . . . . . 33 3.10.1. 構成変更. . . 34 3.10.2の源を特定します。 通知. . . . . . . . . . . . . . . . . . 34 3.10.3の不要な送信を制限します。 他の.37 3.13MIBモジュールデザインが発行する複数のマネージャのためのMIBモジュールを設計する通知サブシステム. . . . . . . . 36 3.11アプリケーションエラー報告. . . . . . . . . . . . . . . 36 3.12のコントロール。 . . . . . . . . . . . . . 39 3.13.1. MIB Moduleの八重奏String Aggregations. . . . . . . . . . . . 39 3.13.2Supporting複数のインスタンス。 . . 40 3.13.3 特別な任意の節の使用。 . . . . . . . . . 41 4. SNMP構成エージェント. . . . . . . . . . . . 41 4.1を実装します。 操作上の一貫性. . . . . . . . . . . . . . . . . 41 4.2。 複数のマネージャを扱います。 . . . . . . . . . . . . . . . 43 4.3. 通りの修正可能性を指定します。 . . . . . . . . . . . . . . 44 4.4. 実装する、書く、-単に、オブジェクトにアクセスしてください。 . . . . . . . . . 44 5. 構成管理ソフトウェアを設計します。 . . . . . . . . . 44 5.1. 管理されたシステムとの構成アプリケーション間連携… 45 5.1 .1。 操作. . . . . . . . . . . . . . . . . . 46 5.1.2を設定してください。 構成トランザクション. . . . . . . . . . . . 46 5.1.3。 構成変更. . . . . . . . . . 47 5.1.4を追跡します。 データの検索のスケーラビリティ。 . . . . . . . . . . 48 6. 展開とセキュリティは.486.1を発行します。 Configuration. . . . . . . . . . 48 6.2に関する基本仮定。 問題. . . . . . . . . . . . . . . 49 6.3をエージェントに保証してください。 認証通知。 . . . . . . . . . . . . . . 49 6.4. 機密情報取り扱い。 . . . . . . . . . . . . . 50 7. 方針を拠点とする管理。 . . . . . . . . . . . . . . . . . . . 51 7.1. '方針ベース'の.51の意味は何です。
MacFaden, et al. Informational [Page 2] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[2ページ]のRFC3512
7.2. Organization of Data in an SNMP-Based Policy System . . . 53
7.3. Information Related to Policy-based Configuration . . . . 54
7.4. Schedule and Time Issues. . . . . . . . . . . . . . . . . 56
7.5. Conflict Detection, Resolution and Error Reporting. . . . 56
7.5.1. Changes to Configuration Outside of the
Policy System. . . . . . . . . . . . . . . . . . . 57
7.6. More about Notifications in a Policy System . . . . . . . 57
7.7. Using Policy to Move Less Configuration Data. . . . . . . 57
8. Example MIB Module With Template-based Data. . . . . . . . . . 58
8.1. MIB Module Definition. . . . . . . . . . . . . . . . . . 61
8.2. Notes on MIB Module with Template-based Data. . . . . . . 73
8.3. Examples of Usage of the MIB . . . . . . .. . . . . . . . 74
9. Security Considerations . . . . . . . . . . .. . . . . . . . . 77
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . 78
11. Normative References. . . . . . . . . . . . . . . . . . . . . 78
12. Informative References. . . . . . . . . . . . . . . . . . . . 79
13. Intellectual Property . . . . . . . . . . . . . . . . . . . . 81
14. Editors' Addresses. . . . . . . . . . . . . . . . . . . . . . 82
15. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 83
7.2. SNMPベースの方針システム. . . 53 7.3における、データの組織。 情報は方針ベースの構成. . . . 54 7.4に関連しました。 スケジュールと時間問題。 . . . . . . . . . . . . . . . . 56 7.5. 闘争検出、解決、および誤り報告。 . . . 56 7.5.1. 方針システムの構成外部への変化。 . . . . . . . . . . . . . . . . . . 57 7.6. さらに方針システム. . . . . . . 57 7.7における通知に関して。 より少ないコンフィギュレーション・データを動かすのに方針を使用します。 . . . . . . 57 8. テンプレートベースのデータがある例のMIBモジュール。 . . . . . . . . . 58 8.1. MIBモジュール定義。 . . . . . . . . . . . . . . . . . 61 8.2. テンプレートベースのデータがあるMIBモジュールに関する注。 . . . . . . 73 8.3. MIBの使用法に関する例… . . . . . . . 74 9. セキュリティ問題… . . . . . . . . 77 10. 承認。 . . . . . . . . . . . . . . . . . . . . . . 78 11. 引用規格。 . . . . . . . . . . . . . . . . . . . . 78 12. 有益な参照。 . . . . . . . . . . . . . . . . . . . 79 13. 知的所有権. . . . . . . . . . . . . . . . . . . . 81 14。 エディタのアドレス。 . . . . . . . . . . . . . . . . . . . . . 82 15. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 83
1. Introduction
1. 序論
1.1. The Internet Standard Management Framework
1.1. インターネットの標準の管理フレームワーク
The Internet Standard Management Framework has many components. The purpose of this document is to describe effective ways of applying those components to the problems of configuration management.
インターネットStandard Management Frameworkには、多くのコンポーネントがあります。 このドキュメントの目的はそれらのコンポーネントを構成管理の問題に適用する効果的な方法を述べることです。
For reference purposes, the Internet Standard Management Framework presently consists of five major components:
参照目的のために、インターネットStandard Management Frameworkは現在、5個の主要コンポーネントから成ります:
o An overall architecture, described in RFC 3411 [1].
o RFC3411[1]で説明された総合的なアーキテクチャ。
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in STD
16, RFC 1155 [15], STD 16, RFC 1212 [16] and RFC 1215 [17]. The
second version, called SMIv2, is described in STD 58, RFC 2578
[2], STD 58, RFC 2579 [3] and STD 58, RFC 2580 [4].
o オブジェクトを説明して、命名するためのメカニズムと管理の目的のためのイベント。 Management情報(SMI)のこのStructureの最初のバージョンは、STD16、RFC1155[15]、STD16、RFC1212[16]、およびRFC1215[17]でSMIv1と呼ばれて、説明されます。 SMIv2と呼ばれる第2バージョンはSTD58、RFC2578[2]、STD58、RFC2579[3]、およびSTD58(RFC2580[4])で説明されます。
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [18]. A second version of the SNMP
message protocol, which is not an Internet standards track
protocol, is called SNMPv2c and described in RFC 1901 [19]. The
third version of the message protocol is called SNMPv3 and
described in RFC 3417 [5], RFC 3412 [6] and RFC 3414 [7].
o 経営情報を移すためのメッセージプロトコル。 SNMPメッセージプロトコルの最初のバージョンは、STD15、RFC1157[18]でSNMPv1と呼ばれて、説明されます。 SNMPメッセージプロトコルの第2のバージョンは、RFC1901[19]でSNMPv2cと呼ばれて、説明されます。(プロトコルはインターネット標準化過程プロトコルではありません)。 メッセージプロトコルの第3バージョンは、RFC3417[5]、RFC3412[6]、およびRFC3414[7]でSNMPv3と呼ばれて、説明されます。
MacFaden, et al. Informational [Page 3] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[3ページ]のRFC3512
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [18]. A second set of protocol
operations and associated PDU formats is described in RFC 3416
[8].
o 経営情報にアクセスするための操作について議定書の中で述べてください。 プロトコル操作と関連PDU形式の第一セットはSTD15、RFC1157[18]で説明されます。 2番目のセットのプロトコル操作と関連PDU形式はRFC3416[8]で説明されます。
o A set of fundamental applications described in RFC 3413 [9] and
the view-based access control mechanism described in RFC 3415
[10].
o 1セットの基礎的応用はRFCで3413[9]について説明しました、そして、視点ベースのアクセス管理機構はRFCで3415[10]について説明しました。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 3410 [12].
RFC3410[12]で現在のSNMP Management Frameworkへの、より詳細な紹介を見つけることができます。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用することで定義されます。
1.2. Configuration and the Internet Standard Management Framework
1.2. 構成とインターネットの標準の管理フレームワーク
Data networks have grown significantly over the past decade. This growth can be seen in terms of:
データ網は過去の10年間かなり成長しています。 以下に関してこの成長を見ることができます。
Scale - Networks have more network elements, and the network
elements are larger and place more demands on the systems managing
them. For example, consider a typical number and speed of
interfaces in a modern core network element. A managed
metropolitan area network switch can have a port density much
greater than the port density built into the expectations of the
management systems that predated it. There are also many more
interrelationships within and between devices and device
functions.
スケール--ネットワークには、より多くのネットワーク要素があって、ネットワーク要素は、より大きく、それらを管理するシステムにより多くの要求を置きます。 例えば、近代的なコアネットワーク要素のインタフェースの典型的な数と速度を考えてください。 管理されたメトロポリタンエリアネットワークスイッチで、ポート密度はポート密度がそれより前に起こったマネージメントシステムへの期待を組み込んだよりはるかにすばらしくなる場合があります。 また、機能以内とデバイスとデバイス機能の間には、ずっと多くの相互関係があります。
Functionality - network devices perform more functions.
More protocols and network layers are required for the successful
deployment of network services which depend on them.
機能性--ネットワークデバイスは、より多くの機能を実行します。 より多くのプロトコルとネットワーク層がそれらによるネットワーク・サービスのうまくいっている展開に必要です。
Rate of Change - the nature of modern network services
causes updates, additions, and deletions of device configuration
information more often than in the past. No longer can it be
assumed that a configuration will be specified once and then be
updated rarely. On the contrary, the trend has been towards much
more frequent changes of configuration information.
Changeのレート--現代のネットワーク・サービスの本質は過去よりしばしばデバイス設定情報のアップデート、追加、および削除を引き起こします。 もう、構成を一度指定して、次に、めったにアップデートしないのは想定できません。 これに反して、傾向は設定情報のはるかに頻繁な変化に向かっています。
Correct configuration of network elements that make up data networks is a prerequisite to the successful deployment of the services on them. The growth in size and complexity of modern networks increases the need for a standard configuration mechanism that is tightly integrated with performance and fault management systems.
データ網を作るネットワーク要素の正しい構成はそれらにおけるうまくいっているサービスの展開への前提条件です。 現代のネットワークのサイズと複雑さにおける成長は性能と障害管理システムについてしっかり統合している標準的な構成メカニズムの必要性を増強します。
MacFaden, et al. Informational [Page 4] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[4ページ]のRFC3512
The Internet Standard Management Framework has been used successfully to develop configuration management systems for a broad range of devices and networks. A standard configuration mechanism that tightly integrates with performance and fault systems is needed not only to help reduce the complexity of management, but also to enable verification of configuration activities that create revenue- producing services.
インターネットStandard Management Frameworkは、広範囲なデバイスとネットワークの構成管理システムを開発するのに首尾よく使用されました。 しっかり性能と欠点システムと統合される標準的な構成メカニズムが、管理の複雑さを減少させるのを単に助けるのではなく、サービスを起こしながら収入を作成する構成活動の検証を可能にもするのに必要です。
This document describes Current Practices that have been used when designing effective configuration management systems using the Internet Standard Management Framework (colloquially known as SNMP). It covers many basic practices as well as more complex agent and manager design issues that are raised by configuration management. We are not endeavoring to present a comprehensive how-to document for generalized SNMP agent, MIB module, or management application design and development. We will, however, cover points of generalized SNMP software design and implementation practice, where the practice has been seen to benefit configuration management software. So, for example, the requirement for management applications to be aware of agent limitations is discussed in the context of configuration operations, but many issues that a management application developer should consider with regard to manager-agent interactions are left for other documents and resources.
このドキュメントはインターネットStandard Management Framework(SNMPとして口語的に知られている)を使用することで有効な構成管理システムを設計するとき使用されたCurrent Practicesについて説明します。 それは構成管理によって育てられるより複雑なエージェントとマネージャデザイン問題と同様に多くの基本的手段をカバーしています。 私たちは、一般化されたSNMPエージェントか、MIBモジュールか、管理アプリケーション設計と開発のための包括的なハウツーもののドキュメントを提示するよう努力していません。 しかしながら、私たちはポイントの一般化されたSNMPソフトウェア設計と実装練習をカバーするつもりです。そこでは、構成管理ソフトウェアのためになるのを習慣を見てあります。 そのように、例えば、構成操作の文脈で管理アプリケーションがエージェント制限を意識しているという要件について議論しますが、管理アプリケーション開発者がマネージャ兼エージェント相互作用に関して考えるべきである多くの問題が他のドキュメントとリソースに残されます。
Significant experience has been gained over the past ten years in configuring public and private data networks with SNMP. During this time, networks have grown significantly as described above. A response to this explosive growth has been the development of policy-based configuration management. Policy-Based Configuration Management is a methodology wherein configuration information is derived from rules and network-wide objectives, and is distributed to potentially many network elements with the goal of achieving consistent network behavior throughout an administrative domain.
SNMPで公共の、そして、個人的なデータ網を構成することにおける過去10年間重要な経験をしています。 この間に、ネットワークは上で説明されるようにかなり成長しました。 この爆発的成長への応答は方針ベースの構成管理の開発です。 ベースの方針Configuration Managementは設定情報が規則とネットワーク全体の目的から得られて、管理ドメイン中で一貫したネットワークの振舞いを達成するという目標がある潜在的に多くのネットワーク要素に分配される方法論です。
This document presents lessons learned from these experiences and applies them to both conventional and policy-based configuration systems based on SNMP.
このドキュメントは、これらの経験から学習されたレッスンを提示して、従来のものとSNMPに基づく同様に方針ベースのコンフィギュレーションシステムにそれらを当てはまります。
2. Using SNMP as a Configuration Mechanism
2. 構成メカニズムとしてSNMPを使用します。
Configuration activity causes one or more state changes in an element. While it often takes an arbitrary number of commands and amount of data to make up configuration change, it is critical that the configuration system treat the overall change operation atomically so that the number of states into which an element transitions is minimized. The goal is for a change request either to be completely executed or not at all. This is called transactional integrity. Transactional integrity makes it possible to develop
構成活動は要素における1回以上の州の変化を引き起こします。 構成変更を作るのにしばしばコマンドとデータ量の特殊活字の数字を要しますが、コンフィギュレーションシステムが要素が移行する州の数が最小にされるように原子論的に総合的な変化操作を扱うのは、重要です。 目標は完全に実行されるよう珍しくどちらかに要求することであるかとんでもない。 これは取引の保全と呼ばれます。 取引の保全で、展開するのは可能になります。
MacFaden, et al. Informational [Page 5] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[5ページ]のRFC3512
reliable configuration systems that can invoke transactions and keep track of an element's overall state and work in the presence of error states.
総合的な要素のものにトランザクションを呼び出して、動向をおさえることができる信頼できるコンフィギュレーションシステムは、州を述べて、誤りがあるとき扱います。
2.1. Transactions and SNMP
2.1. トランザクションとSNMP
Transactions can logically take place at very fine-grained levels such as an individual object instance or in very large aggregations that could include many object instances located in many tables on a managed device. For this reason, reliance on transactional integrity only at the SNMP protocol level is insufficient.
トランザクションは個々のオブジェクトインスタンスなどのきめ細かに非常に粒状のレベルにおいて、または、多くのテーブルに管理されたデバイスに位置する多くのオブジェクトインスタンスを含むことができた非常に大きい集合で論理的に行われることができます。 この理由で、単にSNMPプロトコルレベルにおける取引の保全への信用は不十分です。
2.2. Practical Requirements for Transactional Control
2.2. 取引のコントロールのための実際的な要件
A well-designed and deployed configuration system should have the following features with regard to transactions and transactional integrity.
よく設計されて配布しているコンフィギュレーションシステムには、トランザクションと取引の保全に関して以下の特徴があるはずです。
1) Provide for flexible transaction control at many different levels
of granularity. At one extreme, an entire configuration may be
delivered and installed on an element, or alternately one small
attribute may be changed.
1) 多くの異なったレベルの粒状でフレキシブルなトランザクションコントロールに備えてください。 1つの極端では、全体の構成を要素に提供して、インストールするかもしれませんか、または交互に、1つの小さい属性を変えるかもしれません。
2) The transaction control component should work at and understand a
notion of the kind of multi-level "defaulting" as described in
Section 7.1. The key point here is that it may make most sense to
configure systems at an abstract level rather than on an
individual instance by instance basis as has been commonly
practiced. In some cases it is more effective to send a
configuration command to a system that contains a set of
'defaults' to be applied to instances that meet certain criteria.
2) トランザクションコントロールの部品は、セクション7.1で説明されるように「デフォルトとする」というマルチレベルの種類について機能して、概念を理解しているはずです。 ここの要所は一般的に熟練していたようにインスタンス基礎でオンであるよりむしろ抽象的なレベルでシステムを構成する意味を個々のインスタンスに最もするかもしれないということです。 いくつかの場合、ある評価基準を満たすインスタンスに適用されるために1セットの'デフォルト'を含むシステムに構成コマンドを送るのは、より効果的です。
3) An effective configuration management system must allow
flexibility in the definition of a successful transaction. This
cannot be done at the protocol level alone, but rather must be
provided for throughout the application and the information that
is being managed. In the case of SNMP, the information would be
in properly defined MIB modules.
3) 有効な構成管理システムはうまくいっているトランザクションの定義における柔軟性を許容しなければなりません。 これにプロトコルレベルでは単独ですることができませんが、管理されているアプリケーションと情報中にむしろ備えなければなりません。 SNMPの場合には、情報が適切に定義されたMIBモジュールであるでしょう。
4) A configuration management system should provide time-indexed
transaction control. For effective rollback control, the
configuration transactions and their successful or unsuccessful
completion status must be reported by the managed elements and
stored in a repository that supports such time indexing and can
record the user that made the change, even if the change was not
carried out by the system recording the change.
4) 構成管理システムは時間で索引をつけられたトランザクションコントロールを提供するはずです。 有効なロールバックコントロールのために、構成トランザクションとそれらのうまくいっているか失敗の完成状態は、管理された要素によって報告されて、そのような時間インデックスをサポートする倉庫に保存しなければならなくて、変化が変化を記録するシステムによって行われなかったとしても変更を行ったユーザを記録できます。
MacFaden, et al. Informational [Page 6] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[6ページ]のRFC3512
5) The managed system must support transactional security. This
means that depending on who is making the configuration request
and where it is being made, it may be accepted or denied based on
security policy that is in effect in the managed element.
5) 管理されたシステムは取引のセキュリティをサポートしなければなりません。 これは、だれが構成要求をしているか、そして、それがどこで作られているかによって、管理された要素で有効な安全保障政策に基づいてそれを受け入れるか、または否定するかもしれないことを意味します。
Effective transactional control is a responsibility shared between design, implementation, and operational practice. Transaction control techniques for MIB module design are discussed in Section 3.3. Transaction control considerations for the agent implementation are discussed in Section 5.2.2.
有効な取引のコントロールはデザインと、実装と、操作上の習慣の間で共有された責任です。 セクション3.3でMIBモジュールデザインのためのトランザクション制御方法について議論します。 セクション5.2.2でエージェント実装のためのトランザクションコントロール問題について議論します。
2.3. Practices in Configuration--Verification
2.3. 構成--検証における習慣
Verification of expected behavior subsequent to the commitment of change is an integral part of the configuration process. To reduce the chance of making simple errors in configuration, many organizations employ the following change management procedure:
変化の委任へのその後の予想された振舞いの検証はコンフィギュレーションプロセスの不可欠の部分です。 構成における簡単な誤りをするという可能性を小さくするために、多くの組織が以下の変化管理手順を使います:
pre-test - verify that the system is presently working properly
プレテスト--システムが現在適切に働いていることを確かめてください。
change - make configuration changes and wait for convergence
(system or network stability)
変化--構成変更を作ってください、そして、集合を待ってください。(システムかネットワークの安定性)
re-test - verify once again that the system is working properly
再テストしてください--もう一度システムが適切に働いていることを確かめてください。
This procedure is commonly used to verify configuration changes to critical systems such as the domain name system (DNS). DNS software kits provide diagnostic tools that allow automatic test procedures/scripts to be conducted.
この手順は、ドメイン名システムなどのクリティカル・システムへの構成変更について確かめるのに一般的に用いられます(DNS)。 DNSソフトウェアキットは自動テスト手順/スクリプトが行われるのを許容する診断用道具を提供します。
A planned configuration sequence can be aborted if the pre- configuration test result shows the state of the system as unstable. Debugging the unintended effects of two sets of changes in large systems is often more challenging than an analysis of the effects of a single set after test termination.
プレ構成テスト結果が不安定であるとしてシステムの事情を示しているなら、計画された構成系列を中止できます。 大規模システムにおける、2セットの変化の故意でない効果をデバッグするのはシングルの効果の分析がテスト終了の後にセットしたよりしばしばやりがいがあります。
Networks and devices under SNMP configuration readily support this change management procedure since the SNMP provides integrated monitoring, configuration and diagnostic capabilities. The key is the sequencing of SNMP protocol operations to effect an integrated change procedure like the one described above. This is usually a well-bounded affair for changes within a single network element or node. However, there are times when configuration of a given element can impact other elements in a network. Configuring network protocols such as IEEE 802.1D Spanning Tree or OSPF is especially challenging since the impact of a configuration change can directly affect stability (convergence) of the network the device is connected to.
SNMPが統合モニター、構成、および診断能力を提供するので、SNMP構成の下におけるネットワークとデバイスは容易にこの変化管理手順をサポートします。 キーはもののような統合変化手順が上で説明した効果へのSNMPプロトコル操作の配列です。 通常、これはただ一つのネットワーク要素かノードの中の変化のためのよくバウンドした事です。 しかしながら、与えられた要素の構成がネットワークで他の要素に影響を与えることができる回があります。 構成変更の影響が直接、デバイスが接続されるネットワークの安定性(集合)に影響できるので、IEEE 802.1D Spanning TreeかOSPFなどのネットワーク・プロトコルを構成するのは特にやりがいがあります。
MacFaden, et al. Informational [Page 7] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[7ページ]のRFC3512
An integrated view of configuration and monitoring provides an ideal platform from which to evaluate such changes. For example, the MIB module governing IEEE 802.1D Spanning Tree (RFC 1493 [24]) provides the following object to monitor stability per logical bridge.
構成とモニターの統合視点はそのような変化を評価する理想的なプラットホームを提供します。 例えば、IEEE 802.1D Spanning Treeを治めるMIBモジュール、(RFC1493[24])は、論理的なブリッジあたりの安定性をモニターするために以下のオブジェクトを提供します。
dot1dStpTopChanges OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of topology changes detected by
this bridge since the management entity was last
reset or initialized."
REFERENCE
"IEEE 802.1D-1990: Section 6.8.1.1.3"
::= { dot1dStp 4 }
「経営体が最後にリセットされたか、または初期化されたので、トポロジー変化の総数はこのブリッジで検出した」dot1dStpTopChanges OBJECT-TYPE SYNTAX Counter ACCESSの書き込み禁止のSTATUSの義務的な記述。 参照、「IEEE 802.1D-1990:」 セクション6.8 .1 .1 0.3インチ:、:= dot1dStp4
Likewise, the OSPF MIB module provides a similar metric for stability per OSPF area.
同様に、OSPF MIBモジュールがaを提供する、同様である、OSPF領域あたりの安定性において、メートル法です。
ospfSpfRuns OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of times that the intra-area route
table has been calculated using this area's
link-state database. This is typically done
using Dijkstra's algorithm."
::= { ospfAreaEntry 4 }
ospfSpfRuns OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この領域のリンク州のデータベースを使用することでイントラ領域がテーブルを発送するという回の数について計算されました」。 「これはダイクストラのアルゴリズムを使用し通常終わっています。」 ::= ospfAreaEntry4
The above object types are good examples of a means of facilitating the principles described in Section 2.3. That is, one needs to understand the behavior of a subsystem before configuration change, then be able to use the same means to retest and verify proper operation subsequent to configuration change.
上のオブジェクト・タイプはセクション2.3で説明された原則を容易にする手段の好例です。 すなわち、人は、構成変更にその後で構成変更の前でサブシステムの振舞いを理解して、その時、同じくらいが再テストすることを意味する使用にできて、適切な操作について確かめる必要があります。
The operational effects of a given implementation often differ from one to another for any given standard configuration object. The impact of a change to stability of systems such as OSPF should be documented in an agent-capabilities statement which is consistent with "Requirements for IP Version 4 Routers" [22], Section 1.3.4:
与えられた実装の操作上の効果はどんな与えられた標準的な構成オブジェクトのためにも1〜別のものまでしばしば異なります。 OSPFなどのシステムの安定性への変化の影響は「IPバージョン4ルータのための要件」[22]、セクション1.3.4と一致したエージェント能力声明に記録されるべきです:
A vendor needs to provide adequate documentation on all
configuration parameters, their limits and effects.
ベンダーは、それらのすべての設定パラメータ、限界、および効果に関する適切なドキュメンテーションを提供する必要があります。
MacFaden, et al. Informational [Page 8] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[8ページ]のRFC3512
Adherence to the above model is not fail-safe, especially when configuration errors are masked by long latencies or when configuration errors lead to oscillations in network stability. For example, consider the situation of loading a new software version on a device, which leads to small, slow, cumulative memory leaks brought on by a certain traffic pattern that was not caught during vendor and customer test lab trials.
上のモデルへの固守はフェールセイフではありません、構成誤りが長い潜在で特に隠されるか、または構成誤りがネットワークの安定性で振動につながると。 例えば、ベンダーの間に捕らえられなかったあるトラフィック・パターンと顧客テスト研究室トライアルで起こされた小さくて、遅くて、累積しているメモリリークに通じるデバイスで新しいソフトウェアバージョンをロードする状況を考えてください。
In a network-based example, convergence in an autonomous system cannot be guaranteed when configuration changes are made since there are factors beyond the control of the operator, such as the state of other network elements. Problems affecting this convergence may not be detected for a significant period of time after the configuration change. Even for factors within the operator's control, there is often little verification done to prevent mis-configuration (as shown in the following example).
要素がオペレータのコントロールを超えているので構成変更が作られているとき、ネットワークベースの例では、自律システムでの集合を保証できません、他のネットワーク要素の状態などのように。 この集合に影響することにおける問題は構成変更の後に重要な期間の間、検出されないかもしれません。 オペレータのコントロールの中の要素のためにさえ、誤構成を防ぐためにほとんど行われなかった検証がしばしばあります(以下の例に示されるように)。
Consider a change made to ospfIfHelloInterval and ospfIfRtrDeadInterval [24] timers in the OSPF routing protocol such that both are set to the same value. Two routers may form an adjacency but then begin to cycle in and out of adjacency, and thus never reach a stable (converged) state. Had the configuration process described at the beginning of this section been employed, this particular situation would have been discovered without impacting the production network.
両方が同じ値に設定されるように、OSPFルーティング・プロトコルでospfIfHelloIntervalにされた変更とospfIfRtrDeadInterval[24]がタイマであると考えてください。 2つのルータが隣接番組を形成するかもしれませんが、内外で隣接番組を循環させ始めてください、そして、その結果、安定した(一点に集められる)状態に決して達しないでください。 このセクションの始めに説明されたコンフィギュレーションプロセスが使われたなら、生産ネットワークに影響を与えないで、この特定の状況は発見されたでしょうに。
The important point to remember from this discussion is that configuration systems should be designed and implemented with verification tests in mind.
この議論から覚えている重要なポイントはコンフィギュレーションシステムが念頭で確認試験で設計されていて、実装されるべきであるということです。
3. Designing a MIB Module
3. MIBモジュールを設計します。
Carefully considered MIB module designs are crucial to practical configuration with SNMP. As we have just seen, MIB objects designed for configuration can be very effective since they can be associated with integrated diagnostic, monitoring, and fault objects. MIB modules for configuration also scale when they expose their notion of template object types. Template objects can represent information at a higher level of abstraction than instance-level ones. This has the benefit of reducing the amount of instance-level data to move from management application to the agent on the managed element, when that instance-level data is brought about by applying a template object on the agent. Taken together, all of these objects can provide a robust configuration subsystem.
慎重に考えられたMIBモジュールデザインはSNMPによって実用的な構成に重要です。 私たちがちょうど見たところなように、構成のために設計されたMIBオブジェクトは統合病気の特徴、モニター、および欠点オブジェクトにそれらを関連づけることができるので、非常に効果的である場合があります。 また、テンプレートオブジェクト・タイプに関する彼らの概念を暴露すると、構成のためのMIBモジュールは比例します。 テンプレートオブジェクトはインスタンスレベルものより高いレベルの抽象化で情報を表すことができます。 これには、管理された要素の上で管理アプリケーションからエージェントまで移行するためにインスタンスレベルデータの量を減少させる利益があります、そのインスタンスレベルデータがテンプレートオブジェクトをエージェントに適用することによって引き起こされるとき。 一緒に取って、これらのオブジェクトのすべてが強健な構成サブシステムを提供できます。
The remainder of this section provides specific practices used in MIB module design with SMIv2 and SNMPv3.
このセクションの残りはSMIv2とSNMPv3と共にMIBモジュールデザインに使用される特定の習慣を供給します。
MacFaden, et al. Informational [Page 9] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[9ページ]のRFC3512
3.1. MIB Module Design - General Issues
3.1. MIBモジュールデザイン--一般答弁
One of the first tasks in defining a MIB module is the creation of a model that reflects the scope and organization of the management information an agent will expose.
MIBモジュールを定義することにおける最初のタスクの1つはエージェントが暴露する経営情報の範囲と組織を反映するモデルの作成です。
MIB modules can be thought of as logical models providing one or more aspects/views of a subsystem. The objective for all MIB modules should be to serve one or more operational requirements such as accounting information collection, configuration of one or more parts of a system, or fault identification. However, it is important to include only those aspects of a subsystem that are proven to be operationally useful.
サブシステムに関する1つ以上の局面/意見を提供する論理的なモデルとしてMIBモジュールを考えることができます。 すべてのMIBモジュールのための目的は課金情報収集、システムの1箇所以上の構成、または欠点識別などの1つ以上の操作上の要件に役立つことであるべきです。 しかしながら、操作上役に立つと立証されるサブシステムのそれらの局面だけを含んでいるのは重要です。
In 1993, one of most widely deployed MIB modules supporting configuration was published, RFC 1493, which contained the BRIDGE- MIB. It defined the criteria used to develop the MIB module as follows:
1993年に、構成をサポートするMIBモジュールであると広く配布された大部分の1つは発行されたRFC1493でした。(その1493はBRIDGE- MIBを含みました)。 それは以下のMIBモジュールを開発するのに使用される評価基準を定義しました:
To be consistent with IAB directives and good engineering
practice, an explicit attempt was made to keep this MIB as simple
as possible. This was accomplished by applying the following
criteria to objects proposed for inclusion:
IAB指示と良いエンジニアリング方式と一致しているように、このMIBをできるだけ簡単に保つのを明白な試みをしました。 これは包含のために提案されたオブジェクトに以下の評価基準を適用することによって、達成されました:
(1) Start with a small set of essential objects and add only as
further objects are needed.
(1) 小さいセットの不可欠のオブジェクトから始まってください、そして、単に一層のオブジェクトが必要であるように加えてください。
(2) Require objects be essential for either fault or configuration
management.
(2) オブジェクトを必要としてください。欠点か構成管理のどちらかにおいて、不可欠であってください。
(3) Consider evidence of current use and/or utility.
(3) 現在の使用、そして/または、ユーティリティに関する証拠を考えてください。
(4) Limit the total (sic) of objects.
(4) オブジェクトについて(原文のまま)を総制限してください。
(5) Exclude objects which are simply derivable from others in this
or other MIBs.
(5) これか他のMIBsで単に誘導できるオブジェクトを他のものに入れないようにしてください。
(6) Avoid causing critical sections to be heavily instrumented. The
guideline that was followed is one counter per critical section
per layer.
(6) 危険域が大いに器具を取り付けられることを引き起こすのを避けてください。 1層あたりの危険域あたり従われたガイドラインは1台のカウンタです。
Over the past eight years additional experience has shown a need to expand these criteria as follows:
過去8年間、追加経験は以下のこれらの評価基準を広げる必要性を示しています:
(7) Before designing a MIB module, identify goals and objectives for
the MIB module. How much of the underlying system will be
exposed depends on these goals.
(7) MIBモジュールを設計する前に、MIBモジュールのために目標と目的を特定してください。 基本的なシステムのどのくらいが暴露されるかはこれらの目標によります。
MacFaden, et al. Informational [Page 10] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[10ページ]のRFC3512
(8) Minimizing the total number of objects is not an explicit goal,
but usability is. Be sure to consider deployment and usability
requirements.
(8) オブジェクトの総数を最小にするのは、明確な目標ではありませんが、ユーザビリティは明確な目標です。 展開とユーザビリティ要件を必ず考えてください。
(9) During configuration, consider supporting explicit error state,
capability and capacity objects.
(9) 構成の間、明白な誤りが状態と、能力と容量オブジェクトであるとサポートすると考えてください。
(10) When evaluating rule (5) above, consider the impact on a
management application. If an object can help reduce a
management application's complexity, consider defining objects
that can be derived.
(10) 規則(5)を評価するときには、上では、管理アプリケーションのときに影響を考えてください。 オブジェクトが、管理アプリケーションの複雑さを減少させるのを助けることができるなら、引き出すことができるオブジェクトを定義すると考えてください。
3.2. Naming MIB modules and Managed Objects
3.2. モジュールとManaged ObjectsとMIBを命名します。
Naming of MIB modules and objects informally follows a set of best practices. Originally, standards track MIB modules used RFC names. As the MIB modules evolved, the practice changed to using more descriptive names. Presently, Standards Track MIB modules define a given area of technology such as ATM-MIB, and vendors then extend such MIB modules by prefixing the company name to a given MIB module as in ACME-ATM-MIB.
MIBモジュールとオブジェクトの命名は1セットの最も良い習慣に非公式に続きます。 元々、標準化過程MIBモジュールはRFC名を使用しました。 MIBモジュールが発展したとき、習慣は、より描写的である名前を使用するのに変化しました。 現在、Standards Track MIBモジュールはATM-MIBなどの技術の与えられた領域を定義します、そして、そしてベンダーはACME-ATM-MIBのように与えられたMIBモジュールへ会社名を前に置くことによって、そのようなMIBモジュールを広げます。
Object descriptors (the "human readable names" assigned to object identifiers [2]) defined in standard MIB modules should be unique across all MIB modules. Generally, a prefix is added to each managed object that can help reference the MIB module it was defined in. For example, the IF-MIB uses "if" prefix for descriptors of object types such as ifTable, ifStackTable and so forth.
オブジェクト記述子、(標準のMIBモジュールで定義されたオブジェクト識別子[2])に割り当てられた「人間の読み込み可能な名前」はすべてのMIBモジュールの向こう側にユニークであるべきです。 一般に、接頭語はそれが定義されたMIBモジュールに参照をつけるのを助けることができる各管理オブジェクトに加えられます。 例えば、-、MIB、ifTable、ifStackTableなどなどのオブジェクト・タイプの記述子に“if"接頭語を使用します。
MIB module object type descriptors can include an abbreviation for the function they perform. For example the objects that control configuration in the example MIB module in Section 8 include "Cfg" as part of the object descriptor, as in bldgHVACCfgDesiredTemp.
MIBモジュールオブジェクト・タイプ記述子はそれらが実行する機能のための略語を含むことができます。 例えば、セクション8の例のMIBモジュールで構成を制御するオブジェクトはオブジェクト記述子の一部として"Cfg"を含んでいます、bldgHVACCfgDesiredTempのように。
This is more fully realized when the object descriptors that include the fault, configuration, accounting, performance and security [33] abbreviations are combined with an organized OID assignment approach. For example, a vendor could create a configuration branch in their private enterprises area. In some cases this might be best done on a per product basis. Whatever the approach used, "Cfg" might be included in every object descriptor in the configuration branch. This has two operational benefits. First, for those that do look at instances of MIB objects, descriptors as seen through MIB browsers or other command line tools assist in conveying the meaning of the object type. Secondly, management applications can be pointed at specific subtrees for fault or configuration, causing a more efficient retrieval of data and a simpler management application with potentially better performance.
欠点、構成、会計学、性能、およびセキュリティ[33]略語を含んでいるオブジェクト記述子が組織化されたOID課題アプローチに結合されるとき、これは、より完全に実感されます。 例えば、ベンダーはそれらの私企業領域に構成ブランチを創設できました。 いくつかの場合、1製品基準あたりのaで最も上手にこれをするかもしれません。 アプローチが使用したとしても、ものなら何でも"Cfg"は構成ブランチにおけるあらゆるオブジェクト記述子に含まれているでしょうに。 これには、2つの操作上の利益があります。 まず最初に、MIBオブジェクトのインスタンスを見るものに関してMIBブラウザか他のコマンドラインツールを通して見られる記述子は、オブジェクト・タイプの意味を伝えるのを助けます。 第二に、管理アプリケーションは欠点か構成のために特定の下位木を指すことができます、潜在的により良い性能でデータの、より効率的な検索と、より簡単な管理アプリケーションを引き起こして。
MacFaden, et al. Informational [Page 11] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[11ページ]のRFC3512
3.3. Transaction Control And State Tracking
3.3. トランザクションコントロールと州の追跡
Transactions and keeping track of their state is an important consideration when performing any type of configuration activity regardless of the protocol. Here are a few areas to consider when designing transaction support into an SNMP-based configuration system.
プロトコルにかかわらずどんなタイプの構成活動も実行するとき、それらの状態についてトランザクションと動向をおさえるのは、重要な考慮すべき事柄です。 ここに、SNMPベースのコンフィギュレーションシステムにトランザクションサポートを設計するとき考えるいくつかの領域があります。
3.3.1. Conceptual Table Row Modification Practices
3.3.1. 概念的なテーブル行変更練習
Any discussion of transaction control as it pertains to MIB module design often begins with how the creation or modification of object instances in a conceptual row in the MIB module is controlled.
しばしばMIBモジュールデザインに関するとき、MIBモジュールによる概念的な行における、オブジェクトインスタンスの作成か変更がどう制御されているかでトランザクションコントロールのどんな議論も始まります。
RowStatus [3] is a standard textual convention for the management of conceptual rows in a table. Specifically, the RowStatus textual convention that is used for the SYNTAX value of a single column in a table controls the creation, deletion, activation, and deactivation of conceptual rows of the table. When a table has been defined with a RowStatus object as one of its columns, changing an instance of the object to 'active' causes the row in which that object instance appears to become 'committed'.
RowStatus[3]はテーブルでの概念的な行の管理のための一般的な原文のコンベンションです。 明確に、テーブルの1つのシングル・コラムのSYNTAX値に使用されるRowStatusの原文のコンベンションはテーブルの概念的な行の作成、削除、起動、および非活性化を制御します。 テーブルがRowStatusオブジェクトでコラムの1つと定義されたとき、オブジェクトのインスタンスを'アクティブに'変えることによって、そのオブジェクトインスタンスが現れる行は'遂行される'ようになります。
In a multi-table scenario where the configuration data must be spread over many columnar objects, a RowStatus object in one table can be used to cause the entire set of data to be put in operation or stored based on the definition of the objects.
多くの円柱状のオブジェクトの上にコンフィギュレーション・データを広げなければならないマルチテーブルシナリオでは、1個のテーブルのRowStatusオブジェクトを全体のデータが操作に入れられることを引き起こすのに使用するか、またはオブジェクトの定義に基づいて保存できます。
In some cases, very large amounts of data may need to be 'committed' all at once. In these cases, another approach is to configure all of the rows in all the tables required and have an "activate" object that has a set method that commits all the modified rows.
いくつかの場合、非常に多量のデータが、一気に'遂行される'必要があるかもしれません。 これらの場合では、別のアプローチは、すべてのテーブルの行のすべてが必要であることを構成して、すべての変更された行を遂行するセットメソッドを持っている「動かし」オブジェクトを持つことです。
The RowStatus textual convention specifies that, when used in a conceptual row, a description must define what can be modified. While the description of the conceptual row and its columnar object types is the correct place to derive this information on instance modifiability, it is often wrongly assumed in some implementations that:
RowStatusの原文のコンベンションは、概念的な行に使用されると記述が変更できることを定義しなければならないと指定します。 概念的な行とその円柱状のオブジェクト・タイプの記述がインスタンス修正可能性のこの情報を引き出す正しい場所である間、いくつかの実装でしばしば以下のことと誤って思われます。
1) objects either must all be presently set or none need be set to
make a conceptual RowStatus object transition to active(1)
1) 現在オブジェクトをすべて設定しなければならない、さもなければ、なにもアクティブへの概念的なRowStatusオブジェクト変遷をするように設定される必要はありません。(1)
2) objects in a conceptual row cannot be modified once a RowStatus
object is active(1). Restricting instance modifiability like
this, so that after a RowStatus object is set to active(1) is in
fact a reasonable limitation, since such a set of RowStatus may
have agent system side-effects which depend on committed columnar
2) RowStatusオブジェクトがいったんアクティブな(1)になると、概念的な行のオブジェクトを変更できません。 RowStatusが反対した後にそれがこれアクティブな(1)に設定されて、インスタンス修正可能性を制限して、事実上、RowStatusのそのような1セットにエージェントシステムがあるかもしれなくて以来の合理的な制限は遂行されるところで円柱状の状態でよる副作用ですか?
MacFaden, et al. Informational [Page 12] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[12ページ]のRFC3512
object instance values. However, where this restriction exists on
an object, it should be made clear in a DESCRIPTION clause such as
the following:
オブジェクトインスタンス値。 しかしながら、この制限がオブジェクトの上に存在しているところでは、それは以下などの記述節で明らかにされるべきです:
protocolDirDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (1..64))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"A textual description of the protocol encapsulation.
A probe may choose to describe only a subset of the
entire encapsulation (e.g., only the highest layer).
protocolDirDescr OBJECT-TYPE SYNTAX DisplayString(SIZE(1 .64))マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「プロトコルカプセル化の原文の記述。」 徹底的調査は、全体のカプセル化(例えば、最も高い層だけ)の部分集合だけについて説明するのを選ぶかもしれません。
This object is intended for human consumption only.
このオブジェクトは人間の消費だけで意図します。
This object may not be modified if the associated
protocolDirStatus object is equal to active(1)."
::= { protocolDirEntry 4 }
「関連protocolDirStatusオブジェクトがアクティブな(1)と等しいなら、このオブジェクトは変更されないかもしれません。」 ::= protocolDirEntry4
Any such restrictions on columnar object instance modification while a row's RowStatus object instance is set to active(1) should appear in the DESCRIPTION clause of the RowStatus columnar OBJECT-TYPE as well.
行のRowStatusオブジェクトインスタンスがアクティブな(1)に設定されている間、円柱状のオブジェクトインスタンス変更のどんなそのような制限もまた、RowStatusの円柱状のOBJECT-TYPEの記述節に現れるべきです。
3.3.2. Fate sharing with multiple tables
3.3.2. 複数のテーブルと共有される運命
An important principle associated with transaction control is fate sharing of rows in different tables. Consider the case where a relationship has been specified between two conceptual tables of a MIB module (or tables in two different MIB modules). In this context, fate sharing means that when a row of a table is deleted, the corresponding row in the other table is also deleted. Fate sharing in a transaction control context can also be used with the activation of very large configuration changes. If we have two tables that hold a set of configuration information, a row in one table might have to be put in the 'ready' state before the second can be put in the 'ready' state. When that second table can be placed in the 'ready' state, then the entire transaction can be considered to have been 'committed'.
トランザクションコントロールに関連している重要な原則は異なったテーブルでの行の運命共有です。 関係がMIBモジュール(または、2つの異なったMIBモジュールによるテーブル)の2個の概念的なテーブルの間で指定されたケースを考えてください。 このような関係においては、運命共有は、また、テーブルの行が削除されるときもう片方のテーブルの対応する行が削除されることを意味します。 また、非常に大きい構成変更の起動と共にトランザクションコントロール文脈を分担する運命は使用できます。 私たちが1セットの設定情報を保持する2個のテーブルを持っているなら、'準備ができる'状態に2番目を置くことができる前に1個のテーブルの行は'準備ができる'状態に置かれなければならないかもしれません。 '準備ができる'状態にその第2テーブルを置くことができるなら、全体のトランザクションが'遂行された'と考えることができます。
Fate sharing of SNMP table data should be explicitly defined where possible using the SMI index qualifier AUGMENTS. If the relationship between tables cannot be defined using SMIv2 macros, then the DESCRIPTION clause of the object types which particularly effect the cross-table relationship should define what should happen when rows in related tables are added or deleted.
SNMPテーブルデータの運命共有は、可能であるところでSMIインデックス資格を与える人AUGMENTSを使用することで明らかに定義されるべきです。 SMIv2マクロを使用することでテーブルの間の関係を定義できないなら、特に交差しているテーブル関係に作用するオブジェクト・タイプの記述節は、関連するテーブルの行が加えられるか、または削除されるとき、何が起こるべきであるかを定義するべきです。
MacFaden, et al. Informational [Page 13] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[13ページ]のRFC3512
Consider the relationship between the dot1dBasePortTable and the ifTable. These tables have a sparse relationship. If a given ifEntry supports 802.1D bridging then there is a dot1dBasePortEntry that has a pointer to it via dot1dBasePortIfIndex.
dot1dBasePortTableとifTableとの関係を考えてください。 これらのテーブルには、まばらな関係があります。 与えられたifEntryが802.1Dのブリッジすることをサポートするなら、dot1dBasePortIfIndexを通してそれに指針を持っているdot1dBasePortEntryがあります。
Now, what should happen if an ifEntry that can bridge is deleted? Should the object dot1dBasePortIfIndex simply be set to 0 or should the dot1dBasePortEntry be deleted as well? A number of acceptable design and practice techniques can provide the answer to these questions, so it is important for the MIB module designer to provide the guidance to guarantee consistency and interoperability.
現在、ブリッジすることができるifEntryが削除されるなら、何が起こるべきですか? また、オブジェクトdot1dBasePortIfIndexは単に0に用意ができるべきですか、dot1dBasePortEntryが削除されるべきですか? 多くの許容できるデザインと習慣のテクニックがこれらの質問の答えを提供できるので、MIBモジュールデザイナーが一貫性と相互運用性を保証するために指導を提供するのは、重要です。
To this end, when two tables are related in such a way, ambiguities such as this should be avoided by having the DESCRIPTION clauses of the pertinent row object types define the fate sharing of entries in the respective tables.
2個のテーブルがこのためにそのような方法で関係づけられるとき、適切な行オブジェクト・タイプの記述節にそれぞれのテーブルでのエントリーの運命共有を定義させることによって、これなどのあいまいさは避けられるべきです。
3.3.3. Transaction Control MIB Objects
3.3.3. トランザクションコントロールMIBオブジェクト
When a MIB module is defined that includes configuration object types, consider providing transaction control objects. These objects can be used to cause a large transaction to be committed. For example, we might have several tables that define the configuration of a portion of a system. In order to avoid churn in the operational state of the system we might create a single scalar object that, when set to a particular value, will cause the activation of the rows in all the necessary tables. Here are some examples of further usage for such object types:
構成オブジェクト・タイプを含んでいるMIBモジュールが定義されたら、トランザクションコントロールオブジェクトを提供すると考えてください。 大口の取引が遂行されることを引き起こすのにこれらのオブジェクトを使用できます。 例えば、私たちはシステムの一部の構成を定義する数個のテーブルを持っているかもしれません。 システムの操作上の事情で攪乳器を避けるために、私たちは特定の値に設定されるとすべての必要なテーブルでの行の起動を引き起こす単一のスカラのオブジェクトを作成するかもしれません。 ここに、そのようなオブジェクト・タイプのためのさらなる用法に関するいくつかの例があります:
o Control objects that are the 'write' or 'commit' objects.
o '書いてください'か'公約してください'オブジェクトであるオブジェクトを制御してください。
Such objects can cause all pending transactions (change MIB object
values as a result of SET operations) to be committed to a
permanent repository or operational memory, as defined by the
semantics of the MIB objects.
そのようなオブジェクトで、すべての未定のトランザクション(SET操作の結果、変化MIBオブジェクト値)を永久保存か操作上のメモリに送ることができます、MIBオブジェクトの意味論によって定義されるように。
o Control objects at different levels of configuration granularity.
o 異なったレベルの構成粒状でオブジェクトを制御してください。
One of the decisions for a MIB module designer is what are the
levels of granularity that make sense in practice. For example,
in the routing area, would changes be allowed on a per protocol
basis such as BGP? If allowed at the BGP level, are sub-levels
permitted such as per autonomous system? The design of these
control objects will be impacted by the underlying software
design. RowStatus (see Section 3.3.1) also has important
relevance as a general transaction control object.
MIBモジュールデザイナーのための決定の1つは実際には理解できる粒状のレベルであることです。 例えば、ルーティング領域では、変化がBGPなどのプロトコル基礎あたりのaに許容されるでしょうか? BGPレベルで許容されているなら、自律システムなどのように受入れられたサブレベルは許容されていますか? 基本的なソフトウェアデザインはこれらのコントロールオブジェクトのデザインに影響を与えるでしょう。 また、RowStatus(セクション3.3.1を見る)には、一般的なトランザクションコントロールオブジェクトとして重要な関連性があります。
MacFaden, et al. Informational [Page 14] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[14ページ]のRFC3512
3.3.4. Creating And Activating New Table Rows
3.3.4. 新しいテーブル行を作成して、起動します。
When designing read-create objects in a table, a MIB module designer should first consider the default state of each object in the table when a row is created. Should an implementation of a standard MIB module vary in terms of the objects that need to be set in order to create an instance of a given row, an agent capabilities statement should be used to name the additional objects in that table using the CREATION-REQUIRES clause.
設計がオブジェクトを読書して作成するとき、行が作成されるとき、テーブルでは、MIBモジュールデザイナーは、最初に、デフォルトがテーブルのそれぞれのオブジェクトの状態であると考えるべきです。 標準のMIBモジュールの実装が与えられた行のインスタンスを作成するために設定される必要があるオブジェクトに関して異なるなら、エージェント能力声明は、そのテーブルで追加オブジェクトを命名するのにCREATION-REQUIRES節を使用することで使用されるべきです。
It is useful when configuring new rows to use the notReady status to indicate row activation cannot proceed.
行起動が続くことができないのを示すのにnotReady状態を使用するために新しい行を構成するとき、それは役に立ちます。
When creating a row instance of a conceptual table, one should consider the state of instances of required columnar objects in the row. The DESCRIPTION clause of such a required columnar object should specify it as such.
概念的なテーブルの行インスタンスを作成するとき、行で必要な円柱状のオブジェクトのインスタンスの状態を考えるべきです。 そのような必要な円柱状のオブジェクトの記述節はそういうものとしてそれを指定するべきです。
During the period of time when a management application is attempting to create a row, there may be a period of time when not all of these required (and non-defaultable) columnar object instances have been set. Throughout this time, an agent should return a noSuchInstance error for a GET of any object instance of the row until such time that all of these required instance values are set. The exception is the RowStatus object instance, for which a notReady(3) value should be returned during this period.
管理アプリケーションが行を作成するのを試みる期間の間、これらの必要で(非「デフォルト-可能」)の円柱状のオブジェクトインスタンスのすべてが設定されるというわけではなかった期間があるかもしれません。 今回の間中、インスタンス値がこれらのすべてが必要であることのそのような時に設定されるまで、エージェントは行のどんなオブジェクトインスタンスのGETのためにもnoSuchInstance誤りを返すべきです。 例外はRowStatusオブジェクトインスタンスです。(notReady(3)値はこの期間、そのインスタンスにおいて返されるべきです)。
One need only be concerned with the notReady value return for a RowStatus object when the row under creation does not yet have all of the required, non-defaultable instance values for the row. One approach to simplifying in-row configuration transactions when designing MIB modules is to construct table rows that have no more instance data for columnar objects than will fit inside a single SET PDU. In this case, the createAndWait() value for the RowStatus columnar object is not required. It is possible to use createAndGo() in the same SET PDU, thus simplifying transactional management.
作成の下における行に行のための必要で、非「デフォルト-可能」なインスタンス値のすべてがまだないと、1つはRowStatusオブジェクトのためのnotReady値のリターンに関係があるだけでよいです。 MIBモジュールを設計するとき行の構成トランザクションを簡素化することへの1つのアプローチは独身のSET PDUの中で合うより円柱状のオブジェクトのためのそれ以上のインスタンスデータを全く持っていないテーブル行を構成することです。 この場合、RowStatusの円柱状のオブジェクトのためのcreateAndWait()値は必要ではありません。 同じSET PDUでcreateAndGo()を使用するのは可能であって、その結果、取引の管理を簡素化します。
3.3.5. Summary Objects and State Tracking
3.3.5. 概要オブジェクトと州の追跡
Before beginning a new set of configuration transactions, a management application might want to checkpoint the state of the managed devices whose configuration it is about to change. There are a number of techniques that a MIB module designer can provide to assist in the (re-)synchronization of the managed systems. These objects can also be used to verify that the management application's notion of the managed system state is the same as that of the managed device.
新しいセットの構成トランザクションを始める前に、管理アプリケーションはそれが構成を変えようとしている管理されたデバイスの状態をチェックポイントに必要とするかもしれません。 MIBモジュールデザイナーが助けるために提供できる多くのテクニックがある、(再、)、また. これらのオブジェクトも使用されている場合がある管理されたシステムの同期は、管理アプリケーションの管理されたシステム状態の概念が管理されたデバイスのものと同じであることを確かめます。
MacFaden, et al. Informational [Page 15] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[15ページ]のRFC3512
These techniques include:
これらのテクニックは:
1. Provide an object that reports the number of rows in a table
1. テーブルの行の数を報告するオブジェクトを提供してください。
2. Provide an object that flags when data in the table was last
modified.
2. テーブルのデータが最後に変更されたとき弛むオブジェクトを提供してください。
3. Send a notification message (InformRequests are preferable) to
deliver configuration change.
3. 構成変更を提供する通知メッセージ(InformRequestsは望ましい)を送ってください。
By providing an object containing the number of rows in a table, management applications can decide how best to retrieve a given table's data and may choose different retrieval strategies depending on table size. Note that the availability of and application monitoring of such an object is not sufficient for determining the presence of table data change over a checkpointed duration since an equal number of row creates and deletes over that duration would reflect no change in the object instance value. Additionally, table data change which does not change the number of rows in the table would not be reflected through simple monitoring of such an object instance.
テーブルの行の数を含むオブジェクトを提供することによって、管理アプリケーションは、与えられたテーブルのデータを最もよく検索する方法を決めることができて、テーブル・サイズに依存する異なった検索戦略を選ぶかもしれません。 それに注意してください、有用性、そして、等しい段数以来のcheckpointed持続時間の上の変化がその持続時間の上で作成して、削除するテーブルデータの存在がオブジェクトインスタンス価値における変化を全く反映しないことを決定するオブジェクトが十分でないそのようなもののアプリケーションモニター。 さらに、テーブルの行の数を変えないテーブルデータ変化がそのようなオブジェクトインスタンスの簡単なモニターで反映されないでしょう。
Instead, the change in the value of any table object instance data can be tracked through an object that monitors table change state as a function of time. An example is found in RFC 2790, Host Resources MIB:
代わりに、時間の関数としてテーブル状態遷移をモニターするオブジェクトを通してどんなテーブルオブジェクトインスタンスデータの値における変化も追うことができます。 Host Resources MIB、例はRFC2790で見つけられます:
hrSWInstalledLastUpdateTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the hrSWInstalledTable
was last completely updated. Because caching of this
data will be a popular implementation strategy,
retrieval of this object allows a management station
to obtain a guarantee that no data in this table is
older than the indicated time."
::= { hrSWInstalled 2 }
hrSWInstalledLastUpdateTime OBJECT-TYPE SYNTAX TimeTicksのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「hrSWInstalledTableであるときに、最後にsysUpTimeの値を完全にアップデートしました」。 「このデータのキャッシュがポピュラーな実装戦略になるので、管理局はこのオブジェクトの検索で、このテーブルでどんなデータも示された時間ほど古くないという保証を得ることができます。」 ::= hrSWInstalled2
A similar convention found in many standards track MIB modules is the "LastChange" type object.
多くの標準化過程MIBモジュールで見つけられた同様のコンベンションは"LastChange"タイプオブジェクトです。
For example, the ENTITY-MIB, RFC 2737 [34], provides the following object:
例えば、ENTITY-MIB(RFC2737[34])は以下のオブジェクトを提供します:
entLastChangeTime OBJECT-TYPE
SYNTAX TimeStamp
entLastChangeTimeオブジェクト・タイプ構文タイムスタンプ
MacFaden, et al. Informational [Page 16] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[16ページ]のRFC3512
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time a conceptual row is
created, modified, or deleted in any of these tables:
- entPhysicalTable
- entLogicalTable
- entLPMappingTable
- entAliasMappingTable
- entPhysicalContainsTable"
::= { entityGeneral 1 }
マックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「概念的な行がこれらのテーブルのいずれでも作成されるか、変更されるか、または削除される時のsysUpTimeの値:」 - 「entPhysicalTable--entLogicalTable--entLPMappingTable--entAliasMappingTable--entPhysicalContainsTable」:、:= entityGeneral1
This convention is not formalized. There tend to be small differences in what a table's LastChanged object reflects. IF-MIB (RFC 2863 [20]) defines the following:
このコンベンションは正式にされません。 テーブルのLastChangedオブジェクトが反映することの小さい違いはある傾向があります。 -、MIB、(RFC2863[20])は以下を定義します:
ifTableLastChange OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the last
creation or deletion of an entry in the ifTable. If
the number of entries has been unchanged since the
last re-initialization of the local network management
subsystem, then this object contains a zero value."
::= { ifMIBObjects 5 }
ifTableLastChange OBJECT-TYPE SYNTAX TimeTicksのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「最後の作成時点のsysUpTimeの値かifTableでのエントリーの削除。」 「企業内情報通信網管理サブシステムの最後の再初期化以来エントリーの数が変わりがないなら、このオブジェクトはaゼロ値を含んでいます。」 ::= ifMIBObjects5
So, if an agent modifies a row with an SNMP SET on ifAdminStatus, the value of ifTableLastChange will not be updated. It is important to be specific about what can cause an object to update so that management applications will be able to detect and more properly act on these changes.
それで、エージェントがifAdminStatusの上のSNMP SETと共に行を変更すると、ifTableLastChangeの値をアップデートしないでしょう。 具体的に言うと、何が管理アプリケーションができるようにアップデートへのオブジェクトを引き起こす場合があるかに関して、これらの変化を検出して、より適切に影響するのは重要です。
The final way to keep distributed configuration data consistent is to use an event-driven model, where configuration changes are communicated as they occur. When the frequency of change to configuration is relatively low or polling a cache object is not desired, consider defining a notification that can be used to report all configuration change details.
分配されたコンフィギュレーション・データを一貫しているように保つ最終的な方法はイベントドリブンモデルを使用することです。そこでは、起こるとき、構成変更が伝えられます。 構成への変化の頻度が比較的低いか、またはキャッシュオブジェクトに投票するのが望まれていないとき、すべての構成変更の詳細を報告するのに使用できる通知を定義すると考えてください。
When doing so, the option is available to an SNMPv3 (or SNMPv2c) agent to deliver the notification using either a trap or an inform. The decision as to which PDU to deliver to the recipient is generally a matter of local configuration. Vendors should recommend the use of informs over traps for NOTIFICATION-TYPE data since the agent can use the presence or absence of a response to help know whether it needs
または、そうするとき、罠を使用することで通知を提供するSNMPv3(または、SNMPv2c)エージェントにとって、オプションが利用可能である、知らせてください。 一般に、どのPDUを受取人に提供したらよいかに関する決定は地方の構成の問題です。 ベンダーが使用を推薦するべきである、エージェントが知るのを助けるのに応答の存在か欠如を使用できるのでNOTIFICATION-TYPEデータのために罠の上で知らせる、それが必要です。
MacFaden, et al. Informational [Page 17] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[17ページ]のRFC3512
to retransmit or not. Overall, it is preferable to use an inform instead of a trap so that changes have a higher likelihood of confirmed end-to-end delivery.
再送するために。 全体的に見て、それが使用するために望ましい、罠の代わりに、変化には終わりから終わりへの確認された配送の、より高い見込みがあるように、知らせてください。
As a matter of MIB module design, when practical, the NOTIFICATION- TYPE should include in the PDU all of the modified columnar objects in a row of a table. This makes it easier for the management application receiving the notification to keep track of what has changed in the row of a table and perform addition analysis on the state of the managed elements.
実用的であるときに、MIBモジュールデザインの問題として、NOTIFICATION- TYPEはPDUにテーブルで並んでいる変更された円柱状のオブジェクトのすべてを含んでいるはずです。 これで、テーブルの行で変化したものの動向をおさえて、管理された要素の状態の追加分析を実行するのは通知を受け取る管理アプリケーションには、より簡単になります。
However, the use of notifications to communicate the state of a rapidly changing object may not be ideal either. This leads us back to the MIB module design question of what is the right level of granularity to expose.
しかしながら、急速に変化しているオブジェクトの状態を伝える通知の使用は理想的でないかもしれません。 これは何が暴露する粒状の正しいレベルであるかに関するMIBモジュールデザイン質問に私たちを返します。
Finally, having to poll many "LastChange" objects does not scale well. Consider providing a global LastChange type object to represent overall configuration in a given agent implementation.
最終的に、多くの"LastChange"オブジェクトに投票しなければならないのはよく比例しません。 与えられたエージェント実装における総合的な構成を表すためにグローバルなLastChangeタイプオブジェクトを提供すると考えてください。
3.3.6. Optimizing Configuration Data Transfer
3.3.6. コンフィギュレーション・データ転送を最適化します。
Configuration management software should keep track of the current configuration of all devices under its control. It should ensure that the result is a consistent view of the configuration of the network, which can help reduce inadvertent configuration errors.
構成管理ソフトウェアはコントロールの下におけるすべてのデバイスの現在の構成の動向をおさえるはずです。 それは、結果が不注意な構成誤りを抑えるのを助けることができるネットワークの構成の一貫した視点であることを確実にするべきです。
In devices that have very large amounts of configuration data, it can be costly to both the agent and the manager to have the manager periodically poll the entire contents of these configuration tables for synchronization purposes. A benefit of good synchronization between the manager and the agent is that the manager can determine the smallest and most effective set of data to send to managed devices when configuration changes are required. Depending on the table organization in the managed device and the agent implementation, this practice can reduce the burden on the managed device for activation of these configuration changes.
非常に多量のコンフィギュレーション・データを持っているデバイスでは、マネージャを同期目的のためにこれらの構成テーブルの全体のコンテンツに定期的に投票させるのは、エージェントとマネージャの両方に高価である場合があります。 マネージャとエージェントの間の良い同期の恩恵は構成変更が必要であるときに、マネージャが、最も小さくて最も効果的なデータが管理されたデバイスに発信すると決心できるということです。 管理されたデバイスとエージェント実装におけるテーブル組織によって、この習慣はこれらの構成変更の起動のための管理されたデバイスで負担を減少させることができます。
In the previous section, we discussed the "LastChange" style of object. When viewed against the requirements just described, the LastChange object is insufficient for large amounts of data.
前項で、私たちはオブジェクトの"LastChange"スタイルについて議論しました。 ただ説明された要件に対して見られると、多量のデータに、LastChangeオブジェクトは不十分です。
There are three design options that can be used to assist with the synchronization of the configuration data found in the managed device with the manager:
マネージャと共に管理されたデバイスで見つけられたコンフィギュレーション・データの同期を助けるのに使用できる3つのデザインオプションがあります:
MacFaden, et al. Informational [Page 18] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[18ページ]のRFC3512
1) Design multiple indices to partition the data in a table logically
or break a table into a set of tables to partition the data based
on what an application will use the table for
1) 複数のインデックスリストを設計して、テーブルのデータを論理的に仕切るか、またはテーブルを1セットのテーブルに細かく分けて、アプリケーションが何にテーブルを使用するかに基づくデータを仕切ってください。
2) Use a time-based indexing technique
2) 時間ベースのインデックスのテクニックを使用してください。
3) Define a control MIB module that manages a separate data delivery
protocol
3) 別々のデータ配送プロトコルを管理するコントロールMIBモジュールを定義してください。
3.3.6.1. Index Design
3.3.6.1. インデックスデザイン
Index design has a major impact on the amount of data that must be transferred between SNMP entities and can help to mitigate scaling issues with large tables.
インデックスデザインはSNMP実体の間に移さなければならなくて、大きいテーブルのスケーリング問題を緩和するのを助けることができるデータ量に強い影響を持っています。
Many tables in standard MIB modules follow one of two indexing models:
標準のMIBモジュールによる多くのテーブルが2つの索引をつけているモデルのひとりに続きます:
- Indexing based upon increasing Integer32 or Unsigned32 values of
the kind one might find in an array.
- インデックスは1つが配列で見つけるかもしれない種類の値を増加するInteger32かUnsigned32に基礎づけました。
- Associative indexing, which refers to the technique of using
potentially sparse indices based upon a "key" of the sort one
would use for a hash table.
- 結合しやすいインデックス。(そのインデックスは1つがハッシュ表に使用する種類の「キー」に基づく潜在的にまばらなインデックスリストを使用するテクニックを示します)。
When tables grow to a very large number of rows, using an associative indexing scheme offers the useful ability to efficiently retrieve only the rows of interest.
テーブルが非常に多くの行に成長すると、結合しやすいインデックス体系を使用すると、効率的に興味がある行だけを検索する役に立つ能力は提供されます。
For example, if an SNMP entity exposes a copy of the default-free Internet routing table as defined in the ipCidrRouteTable, it will presently contain around 100,000 rows.
例えば、SNMP実体がipCidrRouteTableで定義されるように無デフォルトのインターネット経路指定テーブルのコピーを暴露すると、それは現在、およそ10万の行を含むでしょう。
Associative indexing is used in the ipCidrRouteTable and allows one to retrieve, for example, all routes for a given IPv4 destination 192.0.2/24.
結合しやすいインデックスは、ipCidrRouteTableで使用されて、1つが与えられたIPv4目的地192.0.2/24のために例えばすべてのルートを検索するのを許容します。
Yet, if the goal is to extract a copy of the table, the associative indexing reduces the throughput and potentially the performance of retrieval. This is because each of the index objects are appended to the object identifiers for every object instance returned.
しかし、目標がテーブルのコピーを抽出することであるなら、結合しやすいインデックスは検索のスループットと潜在的に性能を減らします。 これはあらゆるオブジェクトインスタンスのための識別子が返したオブジェクトにそれぞれのインデックスオブジェクトを追加するからです。
ipCidrRouteEntry OBJECT-TYPE
SYNTAX IpCidrRouteEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A particular route to a particular destination,
ipCidrRouteEntry OBJECT-TYPE SYNTAX IpCidrRouteEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定の目的地への特定のルート」
MacFaden, et al. Informational [Page 19] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[19ページ]のRFC3512
under a particular policy."
INDEX {
ipCidrRouteDest,
ipCidrRouteMask,
ipCidrRouteTos,
ipCidrRouteNextHop
}
「特定の方針。」 インデックスipCidrRouteDest、ipCidrRouteMask、ipCidrRouteTos、ipCidrRouteNextHop
A simple array-like index works efficiently since it minimizes the index size and complexity while increasing the number of rows that can be sent in a PDU. If the indexing is not sparse, concurrency can be gained by sending multiple asynchronous non-overlapping collection requests as is explained in RFC 2819 [32], Page 41 (in the section pertaining to Host Group indexing).
PDUで送ることができる行の数を増強している間、インデックスサイズと複雑さを最小にするので、簡単な配列のようなインデックスは効率的に働いています。 インデックスがまばらでないなら、RFC2819[32]で説明される収集要求を複数の非同期な非の重なるのに送ることによって、並行性を獲得できます、41ページ(Host Groupインデックスに関係するセクションで)。
Should requirements dictate new methods of access, multiple
indices can be defined such that both associative and simple
indexing can coexist to access a single logical table.
アクセスの新しいメソッドを書き取ってください、複数のインデックスリストを定義できるのでともに結合しやすく、簡単なインデックスが単一の論理的なテーブルにアクセスするために共存できるという要件はそうするべきです。
Two examples follow.
2つの例が従います。
First, consider the ifStackTable found in RFC 2863 [20] and the ifInvStackTable RFC 2864 [33]. They are logical equivalents with the order of the auxiliary (index) objects simply reversed.
まず最初に、RFC2863[20]で見つけられたifStackTableとifInvStackTable RFC2864が[33]であると考えてください。 それらは単に補助の(インデックス)オブジェクトの注文を逆にしている論理的な同等物です。
ifStackEntry OBJECT-TYPE
SYNTAX IfStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between
two sub-layers, specifying that one sub-layer runs
on 'top' of the other sub-layer. Each sub-layer
corresponds to a conceptual row in the ifTable."
INDEX { ifStackHigherLayer, ifStackLowerLayer }
::= { ifStackTable 1 }
ifStackEntry OBJECT-TYPE SYNTAX IfStackEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「2つの副層の間の特定の関係に関する情報、1つの副層が走る指定'は'もう片方の副層」を付けます。 「各副層はifTableの概念的な行に対応しています。」 ifStackHigherLayer、ifStackLowerLayerに索引をつけてください:、:= ifStackTable1
ifInvStackEntry OBJECT-TYPE
SYNTAX IfInvStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between two
sub-layers, specifying that one sub-layer runs underneath
the other sub-layer. Each sub-layer corresponds to a
conceptual row in the ifTable."
INDEX { ifStackLowerLayer, ifStackHigherLayer }
::= { ifInvStackTable 1 }
ifInvStackEntry OBJECT-TYPE SYNTAX IfInvStackEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「2つの副層の間の特定の関係に関する情報、それを指定して、副層はもう片方の副層の下を動きます」。 「各副層はifTableの概念的な行に対応しています。」 ifStackLowerLayer、ifStackHigherLayerに索引をつけてください:、:= ifInvStackTable1
MacFaden, et al. Informational [Page 20] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[20ページ]のRFC3512
Second, table designs that can factor data into multiple tables with well-defined relationships can help reduce overall data transfer requirements. The RMON-MIB, RFC 2819 [32], demonstrates a very useful technique of organizing tables into control and data components. Control tables contain those objects that are configured and change infrequently, and the data tables contain information to be collected that can be large and may change quite frequently.
2番目に、データを明確な関係がある複数のテーブルの要因として考慮できるテーブルデザインは、総合的なデータ転送要件を減らすのを助けることができます。 RMON-MIB(RFC2819[32])はコントロールとデータ構成要素にテーブルを組織化する非常に役に立つテクニックを示します。 制御卓は、構成されるそれらのオブジェクトを含んでいて、まれに変化します、そして、データテーブルは大きい場合があり、かなり頻繁に変化するかもしれない集められるべき情報を含んでいます。
As an example, the RMON hostControlTable provides a way to specify how to collect MAC addresses learned as a source or destination from a given port that provides transparent bridging of Ethernet packets.
例として、RMON hostControlTableはソースか目的地としてイーサネットパケットを透明なブリッジすることを提供する与えられたポートから学習されたMACアドレスを集める方法を指定する方法を提供します。
Configuration is accomplished using the hostControlTable. It is indexed by a simple integer. While this may seem to be array-like, it is common practice for command generators to encode the ifIndex into this simple integer to provide associative lookup capability.
構成はhostControlTableを使用するのに優れています。 それは簡単な整数によって索引をつけられます。 これは配列のようであるように思えるかもしれませんが、コマンドジェネレータが結合しやすいルックアップ能力を提供するためにこの簡単な整数にifIndexをコード化するのは、一般的な習慣です。
The RMON hostTable and hostTimeTable represent dependent tables that contain the results indexed by the hostControlTable entry.
RMON hostTableとhostTimeTableはhostControlTableエントリーで索引をつけられた結果を含む依存するテーブルを表します。
The hostTable is further indexed by the MAC address which provides the ability to reasonably search for a collection, such as the Organizationally Unique Identifier (OUI), the first three octets of the MAC address.
hostTableは合理的に収集を捜し求める能力を提供するMACアドレスによってさらに索引をつけられます、Organizationally Unique Identifier(OUI)などのように、MACアドレスの最初の3つの八重奏。
The hostTimeTable is designed explicitly for fast transfer of bulk RMON data. It demonstrates how to handle collecting large number of rows in the face of deletions and insertions by providing hostControlLastDeleteTime.
hostTimeTableは大量のRMONデータの速い転送のために明らかに設計されています。 それはhostControlLastDeleteTimeを提供することによってどう削除に直面して多くの行を集めて、入を扱うかを示します。
hostControlLastDeleteTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime when the last entry
was deleted from the portion of the hostTable
associated with this hostControlEntry. If no
deletions have occurred, this value shall be zero."
::= { hostControlEntry 4 }
hostControlLastDeleteTime OBJECT-TYPE SYNTAX TimeTicksのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「最後のエントリーであるときに、sysUpTimeの値はこのhostControlEntryに関連しているhostTableの一部から削除されました」。 「削除が全く起こっていないと、この値はゼロになるでしょう。」 ::= hostControlEntry4
3.3.6.2. Time Based Indexing
3.3.6.2. 時間はインデックスを基礎づけました。
The TimeFilter as defined in RFC 2021 [44] and used in RMON2-MIB and Q-BRIDGE-MIB (RFC 2674 [26]) provides a way to obtain only those rows that have changed on or after some specified period of time has passed.
RFC2021[44]で定義されて、RMON2-MIBとQ-BRIDGE-MIBで使用されるTimeFilter、(2674[26])が期間かいつかの指定された期間の後に変化したそれらの行だけを得る方法を供給するRFCは通りました。
MacFaden, et al. Informational [Page 21] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[21ページ]のRFC3512
One drawback to TimeFilter index tables is that a given row can appear at many points in time, which artificially inflates the size of the table when performing standard getNext or getBulk data retrieval.
TimeFilter割り出しテーブルへの1つの欠点は与えられた行が時間多くのポイントで現れることができるということです。(標準のgetNextかgetBulkデータの検索を実行するとき、人工的に、時間はテーブルのサイズをふくらませます)。
3.3.6.3. Alternate Data Delivery Mechanisms
3.3.6.3. 代替のデータ排紙機構
If the amount of data to transfer is larger than current SNMP design restrictions permit, as in the case of OCTET STRINGS (64k minus overhead of IP/UDP header plus SNMP header plus varbind list plus varbind encoding), consider delivery of the data via an alternate method, such as FTP and use a MIB module to control that data delivery process. In many cases, this problem can be avoided via effective MIB design. In other words, object types requiring this kind of transfer size should be used judiciously, if at all.
移すデータ量が現在のSNMPより多くであるなら、デザイン制限は、OCTET STRINGS(IP/UDPヘッダープラスSNMPヘッダーとvarbindリストプラスvarbindコード化のオーバーヘッドを引いた64k)に関するケースのように可能にして、FTPなどの代替方法でデータの配送を考えて、そのデータ配送過程を制御するのにMIBモジュールを使用します。 多くの場合、有効なMIBデザインでこの問題を避けることができます。 言い換えれば、この種類の転送サイズを必要とするオブジェクト・タイプは賢明にせいぜい使用されるべきです。
There are many enterprise MIB modules that provide control of the TFTP or FTP protocol. Often the SNMP part defines what to send where and setting an object initiates the operation (for an example, refer to the CISCO-FTP-CLIENT-MIB, discussed in [38]).
TFTPかFTPプロトコルのコントロールを提供する多くの企業MIBモジュールがあります。 しばしば、どこを何に送ったらよいかを定義して、オブジェクトを設定するSNMP部分は操作を開始します。(例について、[38])で議論したシスコFTP CLIENT-MIBを参照してください。
Various approaches exist for allowing a local agent process running within the managed node to take a template for an object instance (for example for a set of interfaces), and adapt and apply it to all of the actual instances within the node. This is an architecture for one form of policy-based configuration (see [36], for example). Such an architecture, which must be designed into the agent and some portions of the MIB module, affords the efficiency of specifying many copies of instance data only once, along with the execution efficiency of distributing the application of the instance data to the agent.
様々なアプローチは、管理されたノードの中で稼働する地方のエージェントプロセスがノードの中で実際のインスタンスのすべてにそれをオブジェクトインスタンス(例えば、1セットのインタフェースへの)にテンプレートを取って、適合させて、適用するのを許容するために存在しています。 これは1つのフォームの方針ベースの構成のためのアーキテクチャ(例えば、[36]を見る)です。 そのようなアーキテクチャ(MIBモジュールのエージェントと数個の部分に設計しなければならない)は一度だけ多くのコピーに関するインスタンスデータを指定する効率を提供します、インスタンスデータのアプリケーションをエージェントに配布する実行効率と共に。
Other work is currently underway to improve efficiency for bulk SNMP transfer operations [37]. The objective of these efforts is simply the conveyance of more information with less overhead.
他の仕事は、現在、大量のSNMP転送操作[37]のために能率を増進するために進行中です。 これらの取り組みの目的は単により少ないオーバーヘッドがある詳しい情報の運送です。
3.4. More Index Design Issues
3.4. より多くのインデックスデザイン問題
Section 3.3.5 described considerations for table row index design as it pertains to the synchronization of changes within sizable table rows. This section simply considers how to specify this syntactically and how to manage indices semantically.
セクション3.3.5は、かなり大きいテーブル行の中で変化の同期に関するので、テーブル行インデックスデザインのために問題について説明しました。 このセクションは、どのようにシンタクス上これを指定するか、そして、どのようにインデックスリストを意味的に管理するかを単に考えます。
In many respects, the design issues associated with indices in a MIB module are similar to those in a database. Care must be taken during the design phase to determine how often and what kind of information must be set or retrieved. The next few points provide some guidance.
あらゆる点で、MIBモジュールでインデックスリストに関連しているデザイン問題はデータベースのそれらと同様です。 どれくらいの頻度で決定する設計段階とどういう情報を設定されなければならないか、または検索しなければならないか間、注意しなければなりません。 次の数ポイントが何らかの指導を提供します。
MacFaden, et al. Informational [Page 22] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[22ページ]のRFC3512
3.4.1. Simple Integer Indexing
3.4.1. 簡単な整数インデックス
When indexing tables using simple Integer32 or Unsigned32, start with one (1) and specify the maximum range of the value. Since object identifiers are unsigned long values, a question that arises is why not index from zero (0) instead of one(1)?
簡単なInteger32かUnsigned32を使用することでテーブルに索引をつけるときには1つ(1)から始まってください、そして、価値の最大範囲を指定してください。 オブジェクト識別子が未署名の長い値であるので、インデックスではなく、起こる質問は1つ(1)の代わりに(0)がないのからのなぜですか?
RFC 2578 [2], Section 7.7, page 28 states the following: Instances identified by use of integer-valued objects should be numbered starting from one (i.e., not from zero). The use of zero as a value for an integer-valued index object type should be avoided, except in special cases. Consider the provisions afforded by the following textual convention from the Interfaces Group MIB module [33]:
RFC2578[2]、セクション7.7、28ページは以下を述べます: 1つ(すなわち、ゼロでないのからの)から始めて、整数で評価されたオブジェクトの使用で特定されたインスタンスは付番されるべきです。 特別なケースを除いて、値としてのゼロの整数で大切なインデックスオブジェクト・タイプの使用は避けられるべきです。 Interfaces Group MIBモジュール[33]からの以下の原文のコンベンションによって提供された条項を考えてください:
InterfaceIndexOrZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"This textual convention is an extension of the
InterfaceIndex convention. The latter defines a greater
than zero value used to identify an interface or interface
sub-layer in the managed system. This extension permits the
additional value of zero. the value zero is object-specific
and must therefore be defined as part of the description of
any object which uses this syntax. Examples of the usage of
zero might include situations where interface was unknown,
or when none or all interfaces need to be referenced."
SYNTAX Integer32 (0..2147483647)
InterfaceIndexOrZero:、:= TEXTUAL-CONVENTION DISPLAY-ヒントの「d」STATUSの現在の記述、「この原文のコンベンションはInterfaceIndexコンベンションの拡大です」。 後者は管理されたシステムでどんな値も以前はよくインタフェースかインタフェースを特定していなかったよりすばらしい副層を定義します。 この拡大はゼロの加算値を可能にします。値ゼロをオブジェクト特有であり、したがって、この構文を使用するどんなオブジェクトの記述の一部とも定義しなければなりません。 「インタフェースが未知であった、またはなにもかすべてのインタフェースが、参照をつけられる必要があるとき、ゼロの用法に関する例は状況を含むかもしれません。」 構文Integer32(0..2147483647)
3.4.2. Indexing with Network Addresses
3.4.2. ネットワーク・アドレスで、索引をつけます。
There are many objects that use IPv4 addresses (SYNTAX IpAddress) as indexes. One such table is the ipAddrTable from RFC 2011 [14] IP- MIB. This limits the usefulness of the MIB module to IPv4. To avoid such limitations, use the addressing textual conventions INET- ADDRESS-MIB [13] (or updates to that MIB module), which provides a generic way to represent addresses for Internet Protocols. In using the InetAddress textual convention in this MIB, however, pay heed to the following advisory found in its description clause:
インデックスとしてIPv4アドレス(SYNTAX IpAddress)を使用する多くのオブジェクトがあります。 そのようなテーブルの1つはRFC2011[14]IP MIBからのipAddrTableです。 これはMIBモジュールの有用性をIPv4に制限します。 そのような制限を避けるのに、アドレシングの原文のコンベンションINET- ADDRESS-MIB[13](または、そのMIBモジュールへのアップデート)を使用してください。(INET- ADDRESS-MIBはインターネットプロトコルのためのアドレスを表すジェネリック方法を提供します)。 しかしながら、このMIBのInetAddressの原文のコンベンションを使用する際に、記述節で見つけられた以下の状況報告に注意してください:
When this textual convention is used as the syntax of an index
object, there may be issues with the limit of 128 sub-identifiers
specified in SMIv2, STD 58. In this case, the OBJECT-TYPE
declaration MUST include a 'SIZE' clause to limit the number of
potential instance sub-identifiers.
この原文のコンベンションがインデックスオブジェクトの構文として使用されるとき、SMIv2(STD58)で指定された128のサブ識別子の限界には問題があるかもしれません。 この場合、OBJECT-TYPE宣言は、潜在的インスタンスサブ識別子の数を制限するために'SIZE'節を含まなければなりません。
MacFaden, et al. Informational [Page 23] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[23ページ]のRFC3512
One should consider the SMI limitation on the 128 sub-identifier specification when using certain kinds of network address index types. The most likely practical liability encountered in practice has been with DNS names, which can in fact be in excess of 128 bytes. The problem can be, of course, compounded when multiple indices of this type are specified for a table.
ある種類のネットワーク・アドレスインデックスタイプを使用するとき、128サブ識別子仕様でSMI制限を考えるべきです。 実際には遭遇する中で最もありそうな実用的な責任がDNS名と共にありました。(事実上、名は128バイト以上であるかもしれません)。 このタイプの複数のインデックスリストがテーブルに指定されるとき、問題はもちろん悪化できます。
3.5. Conflicting Controls
3.5. 闘争は制御されます。
MIB module designers should avoid specifying read-write objects that overlap in function partly or completely.
MIBモジュールデザイナーは、機能で一部か完全に重なる読書して書いているオブジェクトを指定するのを避けるべきです。
Consider the following situation where two read-write objects partially overlap when a dot1dBasePortEntry has a corresponding ifEntry.
dot1dBasePortEntryに対応するifEntryがあるときには2が読書して書くオブジェクトが部分的に重ね合わせる以下の状況を考えてください。
The BRIDGE-MIB defines the following managed object:
BRIDGE-MIBは以下の管理オブジェクトを定義します:
dot1dStpPortEnable OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2) }
ACCESS read-write
STATUS mandatory
DESCRIPTION
"The enabled/disabled status of the port."
REFERENCE
"IEEE 802.1D-1990: Section 4.5.5.2"
::= { dot1dStpPortEntry 4 }
dot1dStpPortEnable OBJECT-TYPE SYNTAX INTEGERは(2)であると無効にされた(1)を可能にしました。ACCESSは「ポートの可能にされたか障害がある状態」をSTATUS義務的な記述に読書して書きます。 参照、「IEEE 802.1D-1990:」 セクション4.5 .5 0.2インチ:、:= dot1dStpPortEntry4
The IF-MIB defines a similar managed object:
-、MIB、同様の管理オブジェクトを定義します:
ifAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1), -- ready to pass packets
down(2),
testing(3) -- in some test mode
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The desired state of the interface. The testing(3)
state indicates that no operational packets can be
passed. When a managed system initializes, all
interfaces start with ifAdminStatus in the down(2) state.
As a result of either explicit management action or per
configuration information retained by the managed system,
ifAdminStatus is then changed to either the up(1) or
ifAdminStatus OBJECT-TYPE SYNTAX INTEGERはいくつかのパケット下に(2)、テスト(3)を通過する準備ができている(1)にモードをテストします。マックス-ACCESSは「インタフェースの必要な状態」をSTATUSの現在の記述に読書して書きます。 テスト(3)州は、どんな操作上のパケットも通過できないのを示します。 いつ、管理されたシステムが初期化するか、すべてのインタフェースが下に(2)状態でifAdminStatusから始まります。 または次に、ifAdminStatusが明白な管理活動の結果、管理されたシステムによって保有された設定情報に従って上(1)に変わる。
MacFaden, et al. Informational [Page 24] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[24ページ]のRFC3512
testing(3) states (or remains in the down(2) state)."
::= { ifEntry 7 }
「(3) 州(または、下に(2)州では、残っている)をテストします。」 ::= ifEntry7
If ifAdminStatus is set to testing(3), the value to be returned for dot1dStpPortEnable is not defined. Without clarification on how these two objects interact, management implementations will have to monitor both objects if bridging is detected and correlate behavior.
ifAdminStatusがテスト(3)に用意ができているなら、dot1dStpPortEnableのために返される値は定義されません。 これらの2個のオブジェクトがどう相互作用するかにおける明確化がなければ、管理実装はブリッジするのが検出されるのと相関物振舞いであるなら両方のオブジェクトをモニターしなければならないでしょう。
The dot1dStpPortEnable object type could have been written with more information about the behavior of this object when values of ifAdminStatus which impact it change. For example, text could be added that described proper return values for the dot1dStpPortEnable object instance for each of the possible values of ifAdminStatus.
それに影響を与えるifAdminStatusの値が変化するとき、dot1dStpPortEnableオブジェクト・タイプはこのオブジェクトの動きに関する詳しい情報で書かれたかもしれません。 例えば、それぞれのifAdminStatusの可能な値のためのdot1dStpPortEnableオブジェクトインスタンスのために適切なリターン値について説明したテキストは加えることができました。
In those cases where overlap between objects is unavoidable, then as we have just described, care should be taken in the description of each of the objects to describe their possible interactions. In the case of an object type defined after an incumbent object type, it is necessary to include in the DESCRIPTION of this later object type the details of these interactions.
そして、私たちがちょうど説明したところなようにオブジェクトの間のオーバラップが避けられないそれらの場合では、それらの可能な相互作用について説明するためにそれぞれのオブジェクトの記述で注意するべきです。 現職のオブジェクト・タイプの後に定義されたオブジェクト・タイプの場合では、この後のオブジェクト・タイプの記述にこれらの相互作用の詳細を含むのが必要です。
3.6. Textual Convention Usage
3.6. 原文のコンベンション用法
Textual conventions should be used whenever possible to create a consistent semantic for an oft-recurring datatype.
一貫していた状態でaを作成するのにおいて可能であるときはいつも、原文のコンベンションは使用されるべきです。しばしば再発しているデータ型式において、意味的です。
MIB modules often define a binary state object such as enable/disable or on/off. Current practice is to use existing Textual Conventions and define the read-write object in terms of a TruthValue from SNMPv2-TC [3]. For example, the Q-BRIDGE-MIB [26] defines:
MIBモジュールがしばしば/を可能にするような2進の州のオブジェクトを定義する、無効にする、または、/では、オフです。 現在の習慣は、既存のTextual Conventionsを使用して、TruthValueに関してSNMPv2-TC[3]から読書して書いているオブジェクトを定義することになっています。 例えば、Q-BRIDGE-MIB[26]は以下を定義します。
dot1dTrafficClassesEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The value true(1) indicates that Traffic Classes are
enabled on this bridge. When false(2), the bridge
operates with a single priority level for all traffic."
DEFVAL { true }
::= { dot1dExtBase 2 }
dot1dTrafficClassesEnabled OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSは「値の本当の(1)は、Traffic Classesがこのブリッジで有効にされるのを示すこと」をSTATUSの現在の記述に読書して書きます。 「(2) ブリッジがすべてのトラフィックのためにただ一つの優先順位で虚偽で作動すると。」 DEFVAL、本当:、:= dot1dExtBase2
Textual conventions that have a reasonable chance of being reused in other MIB modules ideally should also be defined in a separate MIB module to facilitate sharing of such object types. For example, all ATM MIB modules draw on the ATM-TC-MIB [39] to reference and utilize common definitions for addressing, service class values, and the like.
また、他のMIBモジュールで再利用されるという妥当な機会を持っている原文のコンベンションは、そのようなオブジェクト・タイプと共有するのを容易にするために別々のMIBモジュールで理想的に定義されるべきです。 例えば、すべてのATM MIBモジュールが、ATM-TC-MIB[39]を参照に利用して、アドレシングのための一般的な定義、サービス階級値、および同様のものを利用します。
MacFaden, et al. Informational [Page 25] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[25ページ]のRFC3512
To simplify management, it is recommended that existing SNMPv2-TC based definitions be used when possible. For example, consider the following object definition:
管理を簡素化するために、可能であるときに、既存のSNMPv2-TCベースの定義が使用されるのは、お勧めです。 例えば、以下のオブジェクト定義を考えてください:
acmePatioLights OBJECT-TYPE
SYNTAX INTEGER {
on(1),
off(2),
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Current status of outdoor lighting."
::= { acmeOutDoorElectricalEntry 3 }
acmePatioLights OBJECT-TYPE SYNTAX INTEGER、(2)の(1)に関して書く、マックス-ACCESSは「屋外照明の現在の状態」をSTATUSの現在の記述に読書して書きます。 ::= acmeOutDoorElectricalEntry3
This could be defined as follows using existing SNMPv2-TC TruthValue.
以下の通り既存のSNMPv2-TC TruthValueを使用することでこれを定義できるでしょう。
acmePatioLightsOn OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRI2096PTION
"Current status of outdoor lighting. When set to true (1),
this means that the lights are enabled and turned on.
When set to false (2), the lights are turned off."
::= { acmeOutDoorElectricalEntry 3 }
acmePatioLightsOn OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSは「屋外照明の現在の状態」をSTATUSの現在のDESCRI2096PTIONに読書して書きます。 本当の(1)に設定されると、これは、ライトが可能にされて、つけられていることを意味します。 「誤った(2)に設定されると、電気は消されます。」 ::= acmeOutDoorElectricalEntry3
3.7. Persistent Configuration
3.7. 永続的な構成
Many network devices have two levels of persistence with regard to configuration data. In the first case, the configuration data sent to the device is persistent only until changed with a subsequent configuration operation, or the system is reinitialized. The second level is where the data is made persistent as an inherent part of the acceptance of the configuration information. Some configuration shares both these properties, that is, that on acceptance of new configuration data it is saved permanently and in memory. Neither of these necessarily means that the data is used by the operational code. Sometimes separate objects are required to activate this new configuration data for use by the operational code.
多くのネットワークデバイスには、コンフィギュレーション・データに関して2つのレベルの固執があります。 前者の場合、デバイスに送られたコンフィギュレーション・データがその後の構成操作に従って変えるまでしか永続的でないか、またはシステムは再初期化されます。 第2レベルはデータが設定情報の承認の固有の部分として永続的にされるところです。 何らかの構成がそれが永久に保存される新しいコンフィギュレーション・データの承認の上と、そして、メモリですなわち、これらの特性、両方のそれを共有します。 これらのどちらも、必ずデータが操作上のコードによって使用されることを意味するというわけではありません。 時々別々のオブジェクトは操作上のコードで使用のためのこの新しいコンフィギュレーション・データを活性化しなければなりません。
However, many SNMP agents presently implement simple persistence models, which do not reflect all the relationships of the configuration data to the actual persistence model as described above. Some SNMP set requests against MIB objects with MAX-ACCESS read-write are written automatically to a persistent store. In other cases, they are not. In some of the latter cases, enterprise MIB
しかしながら、多くのSNMPエージェントが現在、簡単な固執モデルを実装します。(モデルは上で説明されるようにコンフィギュレーション・データのすべての関係を実際の固執モデルに反映するというわけではありません)。 マックス-ACCESSがあるオブジェクトが読書して書くMIBに対するいくつかのSNMPセット要求が自動的に永続的な店に書かれています。 他の場合では、それらはそうではありません。 いくつかの後者のケース、企業MIBで
MacFaden, et al. Informational [Page 26] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[26ページ]のRFC3512
objects are required in order to get standard configuration stored, thus making it difficult for a generic application to have a consistent effect.
オブジェクトが標準的な構成を保存させるのに必要です、その結果、一般的適用には一貫した効果があるのを難しくします。
There are standard conventions for saving configuration data. The first method uses the Textual Convention known as StorageType [3] which explicitly defines a given row's persistence requirement.
コンフィギュレーション・データを保存するための一般的なコンベンションがあります。 最初のメソッドは明らかに与えられた行の固執要件を定義するStorageType[3]として知られているTextual Conventionを使用します。
Examples include the RFC 3231 [25] definition for the schedTable row object schedStorageType of syntax StorageType, as well as similar row objects for virtually all of the tables of the SNMP View-based Access Control Model MIB [10].
例は構文StorageTypeのschedTable行オブジェクトschedStorageTypeのためのRFC3231[25]定義を含んでいます、SNMP ViewベースのAccess Control Model MIB[10]のテーブルのほとんどすべての同様の行オブジェクトと同様に。
A second method for persistence simply uses the DESCRIPTION clause to define how instance data should persist. RFC 2674 [26] explicitly defines Dot1qVlanStaticEntry data persistence as follows:
固執のための2番目のメソッドは、インスタンスデータがどう持続するべきであるかを定義するのに単に記述節を使用します。 RFC2674[26]は明らかに以下のDot1qVlanStaticEntryデータ固執を定義します:
dot1qVlanStaticTable OBJECT-TYPE
SYNTAX SEQUENCE OF Dot1qVlanStaticEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing static configuration information for
each VLAN configured into the device by (local or
network) management. All entries are permanent and will
be restored after the device is reset."
::= { dot1qVlan 3 }
「(ローカルかネットワーク)経営者側によってデバイスに構成された各VLANのための静的な設定情報を含んでいて、Aはテーブルの上に置く」dot1qVlanStaticTable OBJECT-TYPEのSYNTAX SEQUENCE OF Dot1qVlanStaticEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 「デバイスがリセットされた後に、すべてのエントリーが、永久的であり、復元されるでしょう。」 ::= dot1qVlan3
The current practice is a dual persistence model where one can make changes to run-time configuration as well as to a non-volatile configuration read at device initialization. The DISMAN-SCHEDULE-MIB module [25] provides an example of this practice. A row entry of its SchedTable specifies the parameters by which an agent MIB variable instance can be set to a specific value at some point in time and governed by other constraints and directives. One of those is:
現在の習慣はまた、非揮発性の構成に関するランタイム構成への変化が1つでデバイス初期化で読むことができる二元的な固執モデルです。 DISMAN-SCHEDULE-MIBモジュール[25]はこの習慣に関する例を提供します。 時間内に、何らかのポイントにエージェントのMIBの可変インスタンスがどれであるかもしれないかによって特定の値に設定されて、他の規制と指示で治められて、SchedTableの行エントリーはパラメタを指定します。 それらの1つは以下の通りです。
schedStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines whether this scheduled action is kept
in volatile storage and lost upon reboot or if this row is
backed up by non-volatile or permanent storage.
Conceptual rows having the value `permanent' must allow
write access to the columnar objects schedDescr,
schedInterval, schedContextName, schedVariable, schedValue,
and schedAdminStatus. If an implementation supports the
schedStorageType OBJECT-TYPE SYNTAX StorageTypeマックス-ACCESSは「この予定されている動作が揮発性記憶装置で保たれて、失われているか否かに関係なく、リブートかそれともこの行が非揮発性の、または、永久的なストレージで支援されるかどうかに関してこのオブジェクトは定義する」STATUSの現在の記述を読書して作成します。 '永久的'に値を持っていると許容されなければならない概念的な行は円柱状のオブジェクトのschedDescr、schedInterval、schedContextName、schedVariable、schedValue、およびschedAdminStatusへのアクセスを書きます。 実装サポートです。
MacFaden, et al. Informational [Page 27] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[27ページ]のRFC3512
schedCalendarGroup, write access must be also allowed to
the columnar objects schedWeekDay, schedMonth, schedDay,
schedHour, schedMinute."
DEFVAL { volatile }
::= { schedEntry 19 }
schedCalendarGroup、書いてください。「また、円柱状のオブジェクトschedWeekDay、schedMonth、schedDay、schedHourにアクセスを許さなければならない、schedMinute、」 DEFVAL、揮発性:、:= schedEntry19
It is important, however, to reiterate that the persistence is ultimately controlled by the capabilities and features (with respect to the storage model of management data) of the underlying system on which the MIB Module agent is being implemented. This falls into very much the same kind of issue set as, for example, the situation where the size of data storage in the system for a Counter object type is not the same as that in the corresponding MIB Object Type. To generalize, the final word on the "when" and "how" of storage of persistent data is dictated by the system and the implementor of the agent on the system.
しかしながら、MIB Moduleエージェントが実装されている基本的なシステムの能力と特徴(管理データのストレージモデルに関する)によって固執が結局制御されるのを繰り返すのは重要です。 これはCounterオブジェクト・タイプのシステムのデータ保存のサイズが対応するMIB Object Typeのそれと同じでないところで例えば、状況として設定されたたいへん同じ種類の問題になります。 総合するために、永続的なデータのストレージの「いつ」と「どのように」に関する最終的な言葉はシステムでエージェントのシステムと作成者によって決められるか。
3.8. Configuration Sets and Activation
3.8. 構成セットと起動
An essential notion for configuration of network elements with SNMP is awareness of the difference between the set of one or more configuration objects from the activation of those configuration changes in the actual subsystem. That is, it often only makes sense to activate a group of objects as a single 'transaction'.
SNMPがあるネットワーク要素の構成のための不可欠の概念は実際のサブシステムにおけるそれらの構成変更の起動からの1個以上の構成オブジェクトのセットの違いの認識です。 すなわち、それはしばしば単一の'トランザクション'としてオブジェクトのグループを活性化する意味になるだけです。
3.8.1. Operational Activation Considerations
3.8.1. 操作上の起動問題
A MIB module design must consider the implications of the preceding in the context of changes that will occur throughout a subsystem when changes are activated. This is particularly true for configuration changes that are complex. This complexity can be in terms of configuration data or the operational ramifications of the activation of the changes in the managed subsystem. A practical technique to accommodate this kind of activation is the partitioning of contained configuration sets, as it pertains to their being activated as changes. Any complex configuration should have a master on/off switch (MIB object type) as well as strategically placed on/off switches that partition the activation of configuration data in the managed subsystem. These controls play a pivotal role during the configuration process as well as during subsequent diagnostics. Generally, a series of set operations should not cause an agent to activate each object, causing operational instability to be introduced with every changed object instance. To avoid this liability, ideally a series of Set PDUs can install the configuration and a final set series of PDUs can activate the changes.
MIBモジュールデザインは変化が活性であるときにサブシステム中に起こる変化の文脈における先行の含意を考えなければなりません。 複雑な構成変更には、これは特に本当です。 この複雑さは管理されたサブシステムにおける変化の起動のコンフィギュレーション・データか操作上の分岐であることができます。 この種類の起動を収容する実践的技術は含まれた構成セットの仕切りであることです、彼らの変化としての活性の存在に関するとき。 どんな複雑な構成にも、管理されたサブシステムにおける、コンフィギュレーション・データの起動を仕切る戦略上置かれたオンであるかオフなスイッチと同様にオンであるかオフなスイッチ(MIBオブジェクト・タイプ)がマスターのためにあるべきです。 これらのコントロールはコンフィギュレーションプロセスとその後の病気の特徴の間、極めて重要な役割をプレーします。 一般に、エージェントは一連の集合演算で各オブジェクトを活性化するべきではありません、操作上の不安定性があらゆる変えられたオブジェクトインスタンスで導入されることを引き起こして。 この責任を避けるために、理想的に一連のSet PDUsが構成をインストールできます、そして、PDUsのファイナルセットシリーズは変化を動かすことができます。
MacFaden, et al. Informational [Page 28] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[28ページ]のRFC3512
During diagnostic situations, certain on/off switches can be set to localize the perceived error instead of having to remove the configuration.
診断状況の間、あるオンであるかオフなスイッチが構成を取り除かなければならないことの代わりに知覚された誤りをローカライズするように設定できます。
An example of such an object from the OSPF Version 2 MIB [29] is the global ospfAdminStat:
OSPFバージョン2MIB[29]からのそのようなオブジェクトに関する例はグローバルなospfAdminStatです:
ospfAdminStat OBJECT-TYPE
SYNTAX Status
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The administrative status of OSPF in the
router. The value 'enabled' denotes that the
OSPF Process is active on at least one interface;
'disabled' disables it on all interfaces."
::= { ospfGeneralGroup 2 }
ospfAdminStat OBJECT-TYPE SYNTAX Statusマックス-ACCESSは「ルータにおけるOSPFの管理状態」をSTATUSの現在の記述に読書して書きます。 '可能にされた'値は、OSPF Processが少なくとも1つのインタフェースでアクティブであることを指示します。 「'身体障害者'はすべてのインタフェースでそれを無効にします。」 ::= ospfGeneralGroup2
Elsewhere in the OSPF MIB, the semantics of setting ospfAdminStat to enabled(2) are clearly spelled out.
OSPF MIB、可能にされるのにospfAdminStatを設定する意味論におけるほかの場所では、(2)が明確に詳しく説明されます。
The Scheduling MIB [25] exposes such an object on each entry in the scheduled actions table, along with the corresponding stats object type (with read-only ACCESS) on the scheduled actions row instance.
Scheduling MIB[25]は予定されている動作テーブルの各エントリーのときにそのようなオブジェクトを暴露します、予定されている動作の対応する統計オブジェクト・タイプ(書き込み禁止ACCESSと)行インスタンスと共に。
This reflects a recurring basic design pattern which brings about semantic clarity in the object type usage. A table can expose one columnar object type which is strictly for administrative control. When read, an instance of this object type will reflect its last set or defaulted value. A companion operational columnar object type, with MAX-ACCESS of read-only, provides the current state of activation or deactivation resulting from the last set of the administrative columnar instance. It is fully expected that these administrative and operational columnar instances may reflect different values over some period of time of activation latency, which is why they are separate. Further sections display some of the problems which can result from attempting to combine the operational and administrative row columns into a single object type.
これはオブジェクト・タイプ用法における意味明快を引き起こす再発の基本的なデザインパターンを反映します。 テーブルは厳密な運営管理コントロールに賛成する1人の円柱状のオブジェクト・タイプをさらすことができます。 読まれると、このオブジェクト・タイプのインスタンスは最後に設定されたか、デフォルトとした値を反映するでしょう。 仲間の操作上の円柱状のオブジェクト・タイプは管理円柱状のインスタンスの最後のセットからの起動か非活性化の結果になることの現状を書き込み禁止のマックス-ACCESSに供給します。 これらの管理の、そして、操作上の円柱状のインスタンスが起動潜在のいつかの期間にわたって異価を反映するかもしれないと完全に予想されます(それらが別々である理由です)。 操作上の、そして、管理の行コラムを単独のオブジェクト・タイプに結合するのを試みるのからさらなるセクションは結果として生じることができる問題のいくつかを表します。
Note that all of this is independent of the RowStatus columnar object, and the notion of 'activation' as it pertains to RowStatus. A defined RowStatus object type should be strictly concerned with the management of the table row itself (with 'activation' indicating "the conceptual row is available for use by the managed device" [3], and not to be confused with any operational activation semantics).
このすべてがRowStatusの円柱状のオブジェクトから独立していることに注意してください。そうすれば、それとしての'起動'の概念はRowStatusに関係します。 定義されたRowStatusオブジェクト・タイプは厳密にテーブル行自体の管理に関係があるべきである、('起動'が「概念的な行は管理されたデバイスで使用に利用可能であり」[3]を示していてどんな操作上の起動意味論にも混乱しない、)
MacFaden, et al. Informational [Page 29] RFC 3512 Configuring Networks and Devices with SNMP April 2003
MacFaden、他 2003年4月にSNMPでネットワークとデバイスを構成する情報[29ページ]のRFC3512
In the following example, schedAdminStatus controls activation of the scheduled action, and schedOperStatus reports on its operational status:
以下の例では、schedAdminStatusは予定されている動作の起動、および操作上の状態に関するschedOperStatusレポートを制御します:
schedAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The desired state of the schedule."
DEFVAL { disabled }
::= { schedEntry 14 }
(1)を可能にして、(2)であると無効にされて、マックス-ACCESSはSTATUSの現在の記述を読書して作成します。schedAdminStatus OBJECT-TYPE SYNTAX INTEGER、「スケジュールの必要な状態。」 DEFVAL身体障害者:、:= schedEntry14
一覧
スポンサーリンク
