RFC4292 日本語訳
4292 IP Forwarding Table MIB. B. Haberman. April 2006. (Format: TXT=69321 bytes) (Obsoletes RFC2096) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Haberman Request for Comments: 4292 Johns Hopkins University Obsoletes: 2096 April 2006 Category: Standards Track
コメントを求めるワーキンググループB.ハーバーマンの要求をネットワークでつないでください: 4292年のジョーンズ・ホプキンス大学は以下を時代遅れにします。 2096 2006年4月のカテゴリ: 標準化過程
IP Forwarding Table MIB
IP推進テーブルMIB
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version- independent manner. This document obsoletes RFC 2096.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このドキュメントは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それはIPバージョンから独立している方法における、インターネットプロトコル(IP)パケットの推進に関連する管理オブジェクトについて説明します。 このドキュメントはRFC2096を時代遅れにします。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used In This Document ...............................2
3. The Internet-Standard Management Framework ......................2
4. Overview ........................................................2
4.1. Relationship to Other MIBs .................................3
4.1.1. RFC 1213 ............................................3
4.1.2. RFC 1354 ............................................3
4.1.3. RFC 2096 ............................................3
4.1.4. RFC 2011 and 2465 ...................................3
5. Definitions .....................................................3
6. Security Considerations ........................................30
7. Changes from RFC 2096 ..........................................31
8. Normative References ...........................................32
9. Informative References .........................................32
10. Authors and Acknowledgements ..................................33
1. 序論…2 2. このドキュメントで中古のコンベンション…2 3. インターネット標準の管理フレームワーク…2 4. 概要…2 4.1. 他のMIBsとの関係…3 4.1.1. RFC1213…3 4.1.2. RFC1354…3 4.1.3. RFC2096…3 4.1.4. RFC2011と2465…3 5. 定義…3 6. セキュリティ問題…30 7. RFC2096からの変化…31 8. 標準の参照…32 9. 有益な参照…32 10. 作者と承認…33
Haberman Standards Track [Page 1] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[1ページ]RFC4292IP
1. Introduction
1. 序論
This document defines a portion of the Management Information Base (MIB) for use in managing objects related to the forwarding of Internet Protocol (IP) packets in an IP version-independent manner.
このドキュメントはIPのバージョンから独立している方法における、インターネットプロトコル(IP)パケットの推進に関連するオブジェクトを管理することにおける使用のために、Management Information基地の一部(MIB)を定義します。
It should be noted that the MIB definition described herein does not support multiple instances based on the same address family type. However, it does support an instance of the MIB per address family.
ここに説明されたMIB定義が同じアドレスファミリータイプに基づく複数のインスタンスをサポートしないことに注意されるべきです。 しかしながら、それはアドレスファミリーあたりのMIBのインスタンスをサポートします。
2. Conventions Used In This Document
2. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. The Internet-Standard Management Framework
3. インターネット標準の管理フレームワーク
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
現在のインターネット標準のManagement Frameworkについて説明するドキュメントの詳細な概要について、RFC3410[RFC3410]のセクション7を参照してください。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 一般に、MIBオブジェクトはSimple Network Managementプロトコル(SNMP)を通してアクセスされます。 MIBのオブジェクトは、Management情報(SMI)のStructureで定義されたメカニズムを使用することで定義されます。 このメモはSTD58とRFC2578[RFC2578]とSTD58とRFC2579[RFC2579]とSTD58RFC2580[RFC2580]で説明されるSMIv2に対応であるMIBモジュールを指定します。
4. Overview
4. 概要
The MIB consists of one current table and two current global objects.
MIBは1個の現在のテーブルと2個の現在のグローバルなオブジェクトから成ります。
1. The object inetCidrRouteNumber indicates the number of current
routes. This is primarily to avoid having to read the table in
order to determine this number.
1. オブジェクトinetCidrRouteNumberは現在のルートの数を示します。 これは、主としてこの数を測定するためにテーブルを読まなければならないのを避けるためのものです。
2. The object inetCidrRouteDiscards counts the number of valid
routes that were discarded from inetCidrRouteTable for any
reason. This object replaces the ipRoutingDiscards and
ipv6DiscardedRoutes objects.
2. オブジェクトinetCidrRouteDiscardsはどんな理由でもinetCidrRouteTableから捨てられた有効なルートの数を数えます。 このオブジェクトはipRoutingDiscardsとipv6DiscardedRoutesオブジェクトを取り替えます。
3. The inetCidrRouteTable provides the ability to display IP
version-independent multipath CIDR routes.
3. inetCidrRouteTableはIPのバージョンから独立している多重通路CIDRルートを表示する能力を提供します。
Haberman Standards Track [Page 2] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[2ページ]RFC4292IP
4.1. Relationship to Other MIBs
4.1. 他のMIBsとの関係
This MIB definition contains several deprecated and obsolete tables and objects. The following subsections describe the relationship between these objects and other MIB modules.
このMIB定義は数個の推奨しなくて時代遅れのテーブルとオブジェクトを含んでいます。 以下の小区分はこれらのオブジェクトと他のMIBモジュールとの関係について説明します。
4.1.1. RFC 1213
4.1.1. RFC1213
The ipRouteTable object was originally defined in RFC 1213 [RFC1213]. It was updated by ipForwardTable in RFC 1354 [RFC1354].
ipRouteTableオブジェクトは元々、RFC1213[RFC1213]で定義されました。 それはRFC1354[RFC1354]でipForwardTableによってアップデートされました。
4.1.2. RFC 1354
4.1.2. RFC1354
The ipForwardTable object replaced the ipRouteTable object from RFC 1213. It was in turn obsoleted by the ipCidrRouteTable defined in RFC 2096 [RFC2096].
ipForwardTableオブジェクトはRFC1213からipRouteTableオブジェクトを取り替えました。 それはRFC2096[RFC2096]で定義されたipCidrRouteTableによって順番に時代遅れにされました。
In addition, RFC 1354 introduced ipForwardNumber. This object reflects the number of entries found in ipForwardTable. It was obsoleted by ipCidrRouteNumber, defined in RFC 2096.
さらに、RFC1354はipForwardNumberを導入しました。 このオブジェクトはipForwardTableで見つけられたエントリーの数を反映します。 それはRFC2096で定義されたipCidrRouteNumberによって時代遅れにされました。
4.1.3. RFC 2096
4.1.3. RFC2096
In RFC 2096, the ipCidrRouteTable and ipCidrRouteNumber were introduced. The ipCidrRouteTable object supports multipath IP routes having the same network number but differing network masks. The number of entries in that table is reflected in ipCidrRouteNumber. These objects are deprecated by the definitions contained in this MIB definition.
RFC2096では、ipCidrRouteTableとipCidrRouteNumberを導入しました。 ipCidrRouteTableオブジェクトは同じネットワーク・ナンバーの、しかし、異なったネットワークマスクを持っている多重通路IPルートを支えます。 そのテーブルのエントリーの数はipCidrRouteNumberに反映されます。 これらのオブジェクトはこのMIB定義に含まれた定義で推奨しないです。
4.1.4. RFC 2011 and 2465
4.1.4. RFC2011と2465
RFC 2011 [RFC2011] contains the ipRoutingDiscards object, which counts the number of valid routes that have been removed from the ipCidrRouteTable object. The corresponding ipv6DiscardedRoutes object is defined in RFC 2465 [RFC2465]. These objects are deprecated in favor of the version-independent object inetCidrRouteDiscards defined in this MIB.
RFC2011[RFC2011]はipRoutingDiscardsオブジェクトを含んでいます。(それは、ipCidrRouteTableオブジェクトから取り外された有効なルートの数を数えます)。 対応するipv6DiscardedRoutesオブジェクトはRFC2465[RFC2465]で定義されます。 これらのオブジェクトはこのMIBで定義されたバージョンから独立しているオブジェクトinetCidrRouteDiscardsを支持して推奨しないです。
5. Definitions
5. 定義
IP-FORWARD-MIB DEFINITIONS ::= BEGIN
IPの前進のMIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
IpAddress, Integer32, Gauge32,
Counter32 FROM SNMPv2-SMI
RowStatus FROM SNMPv2-TC
SNMPv2-SMI RowStatusからSNMPv2-Tcからモジュールアイデンティティ、オブジェクト・タイプ、IpAddress、Integer32、Gauge32、Counter32をインポートします。
Haberman Standards Track [Page 3] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[3ページ]RFC4292IP
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
InterfaceIndexOrZero FROM IF-MIB
ip FROM IP-MIB
IANAipRouteProtocol FROM IANA-RTPROTO-MIB
InetAddress, InetAddressType,
InetAddressPrefixLength,
InetAutonomousSystemNumber FROM INET-ADDRESS-MIB;
MODULE-COMPLIANCE、OBJECT-GROUP FROM SNMPv2-CONF InterfaceIndexOrZero FROM、-、MIB ip FROM、IP-MIB IANAipRouteProtocol FROM IANA-RTPROTO-MIB InetAddress、InetAddressType、InetAddressPrefixLength、InetAutonomousSystemNumber FROM INET-ADDRESS-MIB。
ipForward MODULE-IDENTITY
LAST-UPDATED "200602010000Z"
ORGANIZATION
"IETF IPv6 Working Group
http://www.ietf.org/html.charters/ipv6-charter.html"
CONTACT-INFO
"Editor:
Brian Haberman
Johns Hopkins University - Applied Physics Laboratory
Mailstop 17-S442
11100 Johns Hopkins Road
Laurel MD, 20723-6099 USA
ipForwardモジュールアイデンティティが"200602010000Z"組織「IETF IPv6作業部会 http://www.ietf.org/html.charters/ipv6-charter.html 」コンタクトインフォメーションをアップデートした、「エディタ:」 ブライアンハーバーマンジョーンズ・ホプキンス大学--応用物理研究所Mailstop 17-S442 11100ジョーンズ・ホプキン道路ローレル20723-6099MD(米国)
Phone: +1-443-778-1319
Email: brian@innovationslab.net
以下に電話をしてください。 +1-443-778-1319 メールしてください: brian@innovationslab.net
Send comments to <ipv6@ietf.org>"
DESCRIPTION
"The MIB module for the management of CIDR multipath IP
Routes.
「 to <ipv6@ietf.org をコメントに送ってください、gt;、」 記述、「CIDR多重通路IP Routesの管理のためのMIBモジュール。」
Copyright (C) The Internet Society (2006). This version
of this MIB module is a part of RFC 4292; see the RFC
itself for full legal notices."
Copyright(C)インターネット協会(2006)。 このMIBモジュールのこのバージョンはRFC4292の一部です。 「完全な法定の通知に関してRFC自身を見てください。」
REVISION "200602010000Z"
DESCRIPTION
"IPv4/v6 version-independent revision. Minimal changes
were made to the original RFC 2096 MIB to allow easy
upgrade of existing IPv4 implementations to the
version-independent MIB. These changes include:
REVISION"200602010000Z"記述「IPv4/v6のバージョンから独立している改正。」 既存のIPv4実装の簡単なアップグレードをバージョンから独立しているMIBに許容するのを最小量の変更をオリジナルのRFC2096MIBにしました。 これらの変化は:
Adding inetCidrRouteDiscards as a replacement for the
deprecated ipRoutingDiscards and ipv6DiscardedRoutes
objects.
推奨しないipRoutingDiscardsとipv6DiscardedRoutesとの交換が反対するようにinetCidrRouteDiscardsを加えます。
Adding a new conformance statement to support the
implementation of the IP Forwarding MIB in a
read-only mode.
読込み専用モードでIP Forwarding MIBの実装をサポートするために新しい順応声明を加えます。
Haberman Standards Track [Page 4] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[4ページ]RFC4292IP
The inetCidrRouteTable replaces the IPv4-specific
ipCidrRouteTable, its related objects, and related
conformance statements.
inetCidrRouteTableはIPv4特有のipCidrRouteTable、関連するオブジェクト、および関連する順応声明を置き換えます。
Published as RFC 4292."
「RFC4292として、発行されます」。
REVISION "199609190000Z"
DESCRIPTION
"Revised to support CIDR routes.
Published as RFC 2096."
REVISION"199609190000Z"記述は「サポートCIDRルートに、復習されました」。 「RFC2096として、発行されます」。
REVISION "199207022156Z"
DESCRIPTION
"Initial version, published as RFC 1354."
::= { ip 24 }
「初期のバージョンであって、RFC1354として発行された」REVISION"199207022156Z"記述。 ::= ip24
inetCidrRouteNumber OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of current inetCidrRouteTable entries that
are not invalid."
::= { ipForward 6 }
inetCidrRouteNumber OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「無効でない現在のinetCidrRouteTableエントリーの数。」 ::= ipForward6
inetCidrRouteDiscards OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of valid route entries discarded from the
inetCidrRouteTable. Discarded route entries do not
appear in the inetCidrRouteTable. One possible reason
for discarding an entry would be to free-up buffer space
for other route table entries."
::= { ipForward 8 }
「有効なルートエントリーの数はinetCidrRouteTableから捨てた」inetCidrRouteDiscards OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 捨てられたルートエントリーはinetCidrRouteTableに現れません。 「エントリーを捨てる1つの可能な理由は他のルートテーブルエントリーにバッファ領域を開けるだろうことです。」 ::= ipForward8
-- Inet CIDR Route Table
-- Inet CIDRルートテーブル
-- The Inet CIDR Route Table deprecates and replaces the -- ipCidrRoute Table currently in the IP Forwarding Table MIB. -- It adds IP protocol independence.
-- Inet CIDR Route Tableが非難して、取り替える、--現在、IP Forwarding Table MIBのipCidrRoute Table。 -- それはIPプロトコル独立を加えます。
inetCidrRouteTable OBJECT-TYPE
SYNTAX SEQUENCE OF InetCidrRouteEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
inetCidrRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF InetCidrRouteEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述
Haberman Standards Track [Page 5] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[5ページ]RFC4292IP
"This entity's IP Routing table."
REFERENCE
"RFC 1213 Section 6.6, The IP Group"
::= { ipForward 7 }
「この実体のIPルート設定テーブル。」 「RFC1213部6.6、IPグループ」という参照:、:= ipForward7
inetCidrRouteEntry OBJECT-TYPE
SYNTAX InetCidrRouteEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A particular route to a particular destination, under a
particular policy (as reflected in the
inetCidrRoutePolicy object).
inetCidrRouteEntry OBJECT-TYPE SYNTAX InetCidrRouteEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「特定の方針の下の特定の目的地(inetCidrRoutePolicyオブジェクトに反映されるように)への特定のルート。」
Dynamically created rows will survive an agent reboot.
ダイナミックに作成された行はエージェントリブートを乗り切るでしょう。
Implementers need to be aware that if the total number
of elements (octets or sub-identifiers) in
inetCidrRouteDest, inetCidrRoutePolicy, and
inetCidrRouteNextHop exceeds 111, then OIDs of column
instances in this table will have more than 128 sub-
identifiers and cannot be accessed using SNMPv1,
SNMPv2c, or SNMPv3."
INDEX {
inetCidrRouteDestType,
inetCidrRouteDest,
inetCidrRoutePfxLen,
inetCidrRoutePolicy,
inetCidrRouteNextHopType,
inetCidrRouteNextHop
}
::= { inetCidrRouteTable 1 }
「Implementersは、inetCidrRouteDest、inetCidrRoutePolicy、およびinetCidrRouteNextHopの要素(八重奏かサブ識別子)の総数が111を超えているなら、このテーブルのコラムインスタンスのOIDsを128以上のサブ識別子を持って、SNMPv1、SNMPv2c、またはSNMPv3を使用することでアクセスできないのを意識している必要があります。」 inetCidrRouteDestType、inetCidrRouteDest、inetCidrRoutePfxLen、inetCidrRoutePolicy、inetCidrRouteNextHopType、inetCidrRouteNextHopに索引をつけてください:、:= inetCidrRouteTable1
InetCidrRouteEntry ::= SEQUENCE {
inetCidrRouteDestType InetAddressType,
inetCidrRouteDest InetAddress,
inetCidrRoutePfxLen InetAddressPrefixLength,
inetCidrRoutePolicy OBJECT IDENTIFIER,
inetCidrRouteNextHopType InetAddressType,
inetCidrRouteNextHop InetAddress,
inetCidrRouteIfIndex InterfaceIndexOrZero,
inetCidrRouteType INTEGER,
inetCidrRouteProto IANAipRouteProtocol,
inetCidrRouteAge Gauge32,
inetCidrRouteNextHopAS InetAutonomousSystemNumber,
inetCidrRouteMetric1 Integer32,
inetCidrRouteMetric2 Integer32,
inetCidrRouteMetric3 Integer32,
InetCidrRouteEntry:、:= 系列、inetCidrRouteDestType InetAddressType、inetCidrRouteDest InetAddress、inetCidrRoutePfxLen InetAddressPrefixLength、inetCidrRoutePolicyオブジェクト識別子、inetCidrRouteNextHopType InetAddressType、inetCidrRouteNextHop InetAddress、inetCidrRouteIfIndex InterfaceIndexOrZero; inetCidrRouteType整数、inetCidrRouteProto IANAipRouteProtocol、inetCidrRouteAge Gauge32、inetCidrRouteNextHopAS InetAutonomousSystemNumber、inetCidrRouteMetric1 Integer32、inetCidrRouteMetric2 Integer32、inetCidrRouteMetric3 Integer32
Haberman Standards Track [Page 6] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[6ページ]RFC4292IP
inetCidrRouteMetric4 Integer32,
inetCidrRouteMetric5 Integer32,
inetCidrRouteStatus RowStatus
}
inetCidrRouteMetric4 Integer32、inetCidrRouteMetric5 Integer32、inetCidrRouteStatus RowStatus
inetCidrRouteDestType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of the inetCidrRouteDest address, as defined
in the InetAddress MIB.
inetCidrRouteDestType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「InetAddress MIBで定義されるようなinetCidrRouteDestアドレスのタイプ
Only those address types that may appear in an actual
routing table are allowed as values of this object."
REFERENCE "RFC 4001"
::= { inetCidrRouteEntry 1 }
「この値が反対するように実際の経路指定テーブルに現れるかもしれないそれらのアドレスタイプだけが許容されています。」 「RFC4001」という参照:、:= inetCidrRouteEntry1
inetCidrRouteDest OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The destination IP address of this route.
「この送付先IPアドレスは発送する」inetCidrRouteDest OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。
The type of this address is determined by the value of
the inetCidrRouteDestType object.
このアドレスのタイプはinetCidrRouteDestTypeオブジェクトの値で決定します。
The values for the index objects inetCidrRouteDest and
inetCidrRoutePfxLen must be consistent. When the value
of inetCidrRouteDest (excluding the zone index, if one
is present) is x, then the bitwise logical-AND
of x with the value of the mask formed from the
corresponding index object inetCidrRoutePfxLen MUST be
equal to x. If not, then the index pair is not
consistent and an inconsistentName error must be
returned on SET or CREATE requests."
インデックスオブジェクトのinetCidrRouteDestとinetCidrRoutePfxLenのための値は一貫しているに違いありません。 いつ、inetCidrRouteDest(1つが存在しているなら、ゾーンインデックスを除く)の値はxです、そしてbitwiseする、マスクの値が対応するインデックスオブジェクトinetCidrRoutePfxLenから形成されているxの論理的なANDがxと等しいに違いないか。 「そうでなければ、次に、インデックス組は一貫していません、そして、SETかCREATE要求のときにinconsistentName誤りを返さなければなりません。」
::= { inetCidrRouteEntry 2 }
::= inetCidrRouteEntry2
inetCidrRoutePfxLen OBJECT-TYPE
SYNTAX InetAddressPrefixLength
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Indicates the number of leading one bits that form the
mask to be logical-ANDed with the destination address
before being compared to the value in the
inetCidrRoutePfxLen OBJECT-TYPE SYNTAX InetAddressPrefixLengthのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「マスクを形成する主な1ビットの数が中に値と比較される前の送付先アドレスがある論理的なANDedであることを示す、」
Haberman Standards Track [Page 7] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[7ページ]RFC4292IP
inetCidrRouteDest field.
inetCidrRouteDest分野。
The values for the index objects inetCidrRouteDest and
inetCidrRoutePfxLen must be consistent. When the value
of inetCidrRouteDest (excluding the zone index, if one
is present) is x, then the bitwise logical-AND
of x with the value of the mask formed from the
corresponding index object inetCidrRoutePfxLen MUST be
equal to x. If not, then the index pair is not
consistent and an inconsistentName error must be
returned on SET or CREATE requests."
インデックスオブジェクトのinetCidrRouteDestとinetCidrRoutePfxLenのための値は一貫しているに違いありません。 いつ、inetCidrRouteDest(1つが存在しているなら、ゾーンインデックスを除く)の値はxです、そしてbitwiseする、マスクの値が対応するインデックスオブジェクトinetCidrRoutePfxLenから形成されているxの論理的なANDがxと等しいに違いないか。 「そうでなければ、次に、インデックス組は一貫していません、そして、SETかCREATE要求のときにinconsistentName誤りを返さなければなりません。」
::= { inetCidrRouteEntry 3 }
::= inetCidrRouteEntry3
inetCidrRoutePolicy OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object is an opaque object without any defined
semantics. Its purpose is to serve as an additional
index that may delineate between multiple entries to
the same destination. The value { 0 0 } shall be used
as the default value for this object."
::= { inetCidrRouteEntry 4 }
inetCidrRoutePolicy OBJECT-TYPE SYNTAX OBJECT IDENTIFIERのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「少しも定義された意味論がなければこれが、反対する不透明なオブジェクトです」。 目的はそれが多回入国の間で同じ目的地に図で表わすかもしれない追加インデックスとして機能することです。 「値0 0はこのオブジェクトにデフォルト値として使用されるものとします。」 ::= inetCidrRouteEntry4
inetCidrRouteNextHopType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The type of the inetCidrRouteNextHop address, as
defined in the InetAddress MIB.
inetCidrRouteNextHopType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「InetAddress MIBで定義されるようなinetCidrRouteNextHopアドレスのタイプ
Value should be set to unknown(0) for non-remote
routes.
値は非リモートなルートのために未知(0)に設定されるべきです。
Only those address types that may appear in an actual
routing table are allowed as values of this object."
REFERENCE "RFC 4001"
::= { inetCidrRouteEntry 5 }
「この値が反対するように実際の経路指定テーブルに現れるかもしれないそれらのアドレスタイプだけが許容されています。」 「RFC4001」という参照:、:= inetCidrRouteEntry5
inetCidrRouteNextHop OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"On remote routes, the address of the next system en
「リモートルート、次のシステムアンのアドレス」のinetCidrRouteNextHop OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述
Haberman Standards Track [Page 8] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[8ページ]RFC4292IP
route. For non-remote routes, a zero length string.
発送します。 非リモートなルート、ゼロ長ストリングのために。
The type of this address is determined by the value of
the inetCidrRouteNextHopType object."
::= { inetCidrRouteEntry 6 }
「このアドレスのタイプはinetCidrRouteNextHopTypeオブジェクトの値で決定します。」 ::= inetCidrRouteEntry6
inetCidrRouteIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The ifIndex value that identifies the local interface
through which the next hop of this route should be
reached. A value of 0 is valid and represents the
scenario where no interface is specified."
::= { inetCidrRouteEntry 7 }
inetCidrRouteIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZeroマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このルートの次のホップに達するべきである局所界面を特定するifIndex値。」 「0の値は、有効であり、インタフェースが全く指定されないシナリオを表します。」 ::= inetCidrRouteEntry7
inetCidrRouteType OBJECT-TYPE
SYNTAX INTEGER {
other (1), -- not specified by this MIB
reject (2), -- route that discards traffic and
-- returns ICMP notification
local (3), -- local interface
remote (4), -- remote destination
blackhole(5) -- route that discards traffic
-- silently
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The type of route. Note that local(3) refers to a
route for which the next hop is the final destination;
remote(4) refers to a route for which the next hop is
not the final destination.
マックス-ACCESSはSTATUSの現在の記述を読書して作成します。inetCidrRouteType OBJECT-TYPE SYNTAX INTEGER、他の(1)--このMIB廃棄物(2)で、指定されません--それを発送するのがトラフィックと--リターンICMP通知ローカル(3)--局所界面のリモート(4)--遠く離れた目的地blackhole(5)--静かにトラフィックを捨てるルートを捨てる、「ルートのタイプ。」 地方の(3)が次のホップが最終的な目的地であるルートを示すことに注意してください。 リモート(4)は次のホップが最終的な目的地でないルートを示します。
Routes that do not result in traffic forwarding or
rejection should not be displayed, even if the
implementation keeps them stored internally.
トラフィック推進か拒絶をもたらさないルートを表示するべきではありません、実装が、内部的にそれらとして保存し続けても。
reject(2) refers to a route that, if matched, discards
the message as unreachable and returns a notification
(e.g., ICMP error) to the message sender. This is used
in some protocols as a means of correctly aggregating
routes.
廃棄物(2)は、合わせられているならメッセージを捨てるルートを手の届かなく呼んで、通知(例えば、ICMP誤り)をメッセージ送付者に返します。 これは正しくルートに集める手段としていくつかのプロトコルに使用されます。
blackhole(5) refers to a route that, if matched,
discards the message silently."
::= { inetCidrRouteEntry 8 }
「blackhole(5)は合わせられているなら静かにメッセージを捨てるルートを示します。」 ::= inetCidrRouteEntry8
Haberman Standards Track [Page 9] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[9ページ]RFC4292IP
inetCidrRouteProto OBJECT-TYPE
SYNTAX IANAipRouteProtocol
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The routing mechanism via which this route was learned.
Inclusion of values for gateway routing protocols is
not intended to imply that hosts should support those
protocols."
::= { inetCidrRouteEntry 9 }
inetCidrRouteProto OBJECT-TYPE SYNTAX IANAipRouteProtocolのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「を通したこのルートが学習されたルーティングメカニズム。」 「ゲートウェイルーティング・プロトコルのための値の包含が、ホストがそれらのプロトコルをサポートするべきであるのを含意することを意図しません。」 ::= inetCidrRouteEntry9
inetCidrRouteAge OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number of seconds since this route was last updated
or otherwise determined to be correct. Note that no
semantics of 'too old' can be implied, except through
knowledge of the routing protocol by which the route
was learned."
::= { inetCidrRouteEntry 10 }
inetCidrRouteAge OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「このルート以来の秒数は、アップデートしたか、または正しいことを別の方法で決定しました」。 「ルートが学習されたルーティング・プロトコルに関する知識を除いて、'古過ぎること'の意味論を全く含意できないことに注意してください。」 ::= inetCidrRouteEntry10
inetCidrRouteNextHopAS OBJECT-TYPE
SYNTAX InetAutonomousSystemNumber
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The Autonomous System Number of the Next Hop. The
semantics of this object are determined by the routing-
protocol specified in the route's inetCidrRouteProto
value. When this object is unknown or not relevant, its
value should be set to zero."
DEFVAL { 0 }
::= { inetCidrRouteEntry 11 }
inetCidrRouteNextHopAS OBJECT-TYPE SYNTAX InetAutonomousSystemNumberマックス-ACCESSは「次の自律システム番号は飛び越す」STATUSの現在の記述を読書して作成します。 このオブジェクトの意味論はルートのinetCidrRouteProto値で指定されたルーティングプロトコルで決定します。 「このオブジェクトが未知である、または関連していないとき、値はゼロに設定されるべきです。」 DEFVAL0:、:= inetCidrRouteEntry11
inetCidrRouteMetric1 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The primary routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's inetCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
inetCidrRouteMetric1 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法のプライマリルーティングは発送する」STATUSの現在の記述を読書して作成します。 これほどメートル法の意味論はルートのinetCidrRouteProto値で指定されたルーティングプロトコルで決定します。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL{ -1 }
Haberman Standards Track [Page 10] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[10ページ]RFC4292IP
::= { inetCidrRouteEntry 12 }
::= inetCidrRouteEntry12
inetCidrRouteMetric2 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's inetCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { inetCidrRouteEntry 13 }
inetCidrRouteMetric2 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法の迂回中継は発送する」STATUSの現在の記述を読書して作成します。 これほどメートル法の意味論はルートのinetCidrRouteProto値で指定されたルーティングプロトコルで決定します。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL-1:、:= inetCidrRouteEntry13
inetCidrRouteMetric3 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's inetCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { inetCidrRouteEntry 14 }
inetCidrRouteMetric3 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法の迂回中継は発送する」STATUSの現在の記述を読書して作成します。 これほどメートル法の意味論はルートのinetCidrRouteProto値で指定されたルーティングプロトコルで決定します。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL-1:、:= inetCidrRouteEntry14
inetCidrRouteMetric4 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's inetCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { inetCidrRouteEntry 15 }
inetCidrRouteMetric4 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法の迂回中継は発送する」STATUSの現在の記述を読書して作成します。 これほどメートル法の意味論はルートのinetCidrRouteProto値で指定されたルーティングプロトコルで決定します。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL-1:、:= inetCidrRouteEntry15
inetCidrRouteMetric5 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
inetCidrRouteMetric5 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法の迂回中継は発送する」STATUSの現在の記述を読書して作成します。 これほどメートル法の意味論はルーティングで決定します。
Haberman Standards Track [Page 11] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[11ページ]RFC4292IP
protocol specified in the route's inetCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { inetCidrRouteEntry 16 }
プロトコルはルートのinetCidrRouteProto値で指定しました。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL-1:、:= inetCidrRouteEntry16
inetCidrRouteStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The row status variable, used according to row
installation and removal conventions.
inetCidrRouteStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「行インストールに従って使用される行状態変数と取り外しコンベンション。」
A row entry cannot be modified when the status is
marked as active(1)."
::= { inetCidrRouteEntry 17 }
「状態がアクティブな(1)として示されるとき、行エントリーを変更できません。」 ::= inetCidrRouteEntry17
-- Conformance information
-- 順応情報
ipForwardConformance
OBJECT IDENTIFIER ::= { ipForward 5 }
ipForwardConformanceオブジェクト識別子:、:= ipForward5
ipForwardGroups
OBJECT IDENTIFIER ::= { ipForwardConformance 1 }
ipForwardGroupsオブジェクト識別子:、:= ipForwardConformance1
ipForwardCompliances
OBJECT IDENTIFIER ::= { ipForwardConformance 2 }
ipForwardCompliancesオブジェクト識別子:、:= ipForwardConformance2
-- Compliance statements
-- 承諾声明
ipForwardFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented for read-create, the
implementation can claim full compliance.
ipForwardFullCompliance MODULE-COMPLIANCE STATUSの現在の記述、「このMIBがいつの間、実装されるか、読書する作成、実装が完全なコンプライアンスを要求できる、」
There are a number of INDEX objects that cannot be
represented in the form of OBJECT clauses in SMIv2,
but for which there are compliance requirements,
expressed in OBJECT clause form in this description:
SMIv2のOBJECT節フォームにこの記述で表現された承諾要件がある、OBJECT節の形に表すことができない多くのINDEXオブジェクトがあります:
-- OBJECT inetCidrRouteDestType
-- SYNTAX InetAddressType (ipv4(1), ipv6(2),
-- ipv4z(3), ipv6z(4))
-- DESCRIPTION
-- This MIB requires support for global and
-- non-global ipv4 and ipv6 addresses.
-- そして、OBJECT inetCidrRouteDestType--、SYNTAX InetAddressType、(ipv4(1)、ipv6(2)、--、ipv4z(3)、ipv6z(4))--記述--このMIBが支持を要するグローバルである、--非グローバルなipv4とipv6アドレス。
Haberman Standards Track [Page 12] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[12ページ]RFC4292IP
--
-- OBJECT inetCidrRouteDest
-- SYNTAX InetAddress (SIZE (4 | 8 | 16 | 20))
-- DESCRIPTION
-- This MIB requires support for global and
-- non-global IPv4 and IPv6 addresses.
--
-- OBJECT inetCidrRouteNextHopType
-- SYNTAX InetAddressType (unknown(0), ipv4(1),
-- ipv6(2), ipv4z(3)
-- ipv6z(4))
-- DESCRIPTION
-- This MIB requires support for global and
-- non-global ipv4 and ipv6 addresses.
--
-- OBJECT inetCidrRouteNextHop
-- SYNTAX InetAddress (SIZE (0 | 4 | 8 | 16 | 20))
-- DESCRIPTION
-- This MIB requires support for global and
-- non-global IPv4 and IPv6 addresses.
"
-- -- そして、OBJECT inetCidrRouteDest--、SYNTAX InetAddress、(SIZE、(16|20、4|8|)、この--記述--MIBが支持を要する、グローバルである、--非グローバルなIPv4とIPv6アドレス。 -- -- そして、OBJECT inetCidrRouteNextHopType--、SYNTAX InetAddressType、(未知(0)、ipv4(1)--ipv6(2)、ipv4z(3)--ipv6z(4))--記述--このMIBが支持を要する、グローバルである、--非グローバルなipv4とipv6アドレス。 -- -- そして、OBJECT inetCidrRouteNextHop--、SYNTAX InetAddress、(SIZE、(8|16|20、0|4|)、この--記述--MIBが支持を要する、グローバルである、--非グローバルなIPv4とIPv6アドレス。 "
MODULE -- this module
MANDATORY-GROUPS { inetForwardCidrRouteGroup }
MODULE--このモジュールMANDATORY-GROUPSinetForwardCidrRouteGroup
OBJECT inetCidrRouteStatus
SYNTAX RowStatus { active(1), notInService (2) }
WRITE-SYNTAX RowStatus { active(1), notInService (2),
createAndGo(4), destroy(6) }
DESCRIPTION "Support for createAndWait is not required."
OBJECT inetCidrRouteStatus SYNTAX RowStatus、アクティブな(1)、notInService(2)、WRITE-SYNTAX RowStatus、能動態(1)、notInService(2)(createAndGo(4))が(6)を破壊する、記述、「createAndWaitのサポートは必要ではありません」。
::= { ipForwardCompliances 3 }
::= ipForwardCompliances3
ipForwardReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented without support for read-
create (i.e., in read-only mode), the implementation can
claim read-only compliance."
MODULE -- this module
MANDATORY-GROUPS { inetForwardCidrRouteGroup }
ipForwardReadOnlyCompliance MODULE-COMPLIANCE STATUSの現在の記述、「このMIBがいつなしで実行されるか、読書のサポートが作成する、(すなわち、読込み専用モードで)実現が、書き込み禁止が承諾であると主張できる、」 MODULE--このモジュールMANDATORY-GROUPSinetForwardCidrRouteGroup
OBJECT inetCidrRouteIfIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteIfIndex MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT inetCidrRouteType
物のinetCidrRouteType
Haberman Standards Track [Page 13] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[13ページ]RFC4292IP
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT inetCidrRouteNextHopAS
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteNextHopAS MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT inetCidrRouteMetric1
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteMetric1 MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT inetCidrRouteMetric2
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteMetric2 MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT inetCidrRouteMetric3
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteMetric3 MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT inetCidrRouteMetric4
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteMetric4 MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT inetCidrRouteMetric5
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteMetric5 MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
OBJECT inetCidrRouteStatus
SYNTAX RowStatus { active(1) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT inetCidrRouteStatus SYNTAX RowStatusのアクティブな(1)、MIN-ACCESS書き込み禁止記述、「書く、アクセスは必要でない、」
::= { ipForwardCompliances 4 }
::= ipForwardCompliances4
-- units of conformance
-- ユニットの順応
inetForwardCidrRouteGroup OBJECT-GROUP
OBJECTS { inetCidrRouteDiscards,
inetCidrRouteIfIndex, inetCidrRouteType,
inetCidrRouteProto, inetCidrRouteAge,
inetForwardCidrRouteGroup物群対象、inetCidrRouteDiscards、inetCidrRouteIfIndex、inetCidrRouteType、inetCidrRouteProto、inetCidrRouteAge
Haberman Standards Track [Page 14] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[14ページ]RFC4292IP
inetCidrRouteNextHopAS, inetCidrRouteMetric1,
inetCidrRouteMetric2, inetCidrRouteMetric3,
inetCidrRouteMetric4, inetCidrRouteMetric5,
inetCidrRouteStatus, inetCidrRouteNumber
}
STATUS current
DESCRIPTION
"The IP version-independent CIDR Route Table."
::= { ipForwardGroups 4 }
inetCidrRouteNextHopAS、inetCidrRouteMetric1、inetCidrRouteMetric2、inetCidrRouteMetric3、inetCidrRouteMetric4、inetCidrRouteMetric5、inetCidrRouteStatus、inetCidrRouteNumber STATUSの現在の記述、「IPのバージョンから独立しているCIDR Route Table。」 ::= ipForwardGroups4
-- Deprecated Objects
-- 推奨しない物
ipCidrRouteNumber OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The number of current ipCidrRouteTable entries that are
not invalid. This object is deprecated in favor of
inetCidrRouteNumber and the inetCidrRouteTable."
::= { ipForward 3 }
ipCidrRouteNumber OBJECT-TYPE SYNTAX Gauge32マックス-ACCESS書き込み禁止STATUSは記述を非難しました。「無効でない現在のipCidrRouteTableエントリーの数。」 「この物はinetCidrRouteNumberとinetCidrRouteTableを支持して非難されます。」 ::= ipForward3
-- IP CIDR Route Table
-- IP CIDRルートテーブル
-- The IP CIDR Route Table obsoletes and replaces the ipRoute -- Table current in MIB-I and MIB-II and the IP Forwarding Table. -- It adds knowledge of the autonomous system of the next hop, -- multiple next hops, policy routing, and Classless -- Inter-Domain Routing.
-- IP CIDR Route TableはipRouteを時代遅れにして、取り替えます--MIB-I、MIB-II、およびIP Forwarding Tableのテーブル電流。 -- それは次のホップ--倍数の次のホップ、方針ルーティング、およびClassless--相互Domainルート設定の自律システムに関する知識を加えます。
ipCidrRouteTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpCidrRouteEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"This entity's IP Routing table. This table has been
deprecated in favor of the IP version neutral
inetCidrRouteTable."
REFERENCE
"RFC 1213 Section 6.6, The IP Group"
::= { ipForward 4 }
ipCidrRouteTable OBJECT-TYPE SYNTAX SEQUENCE OF IpCidrRouteEntryのマックス-ACCESSのアクセスしやすくないSTATUSは「この実体のIPルート設定はテーブルの上に置く」記述を非難しました。 「このテーブルはIPバージョンの中立inetCidrRouteTableを支持して非難されました。」 「RFC1213部6.6、IPグループ」という参照:、:= ipForward4
ipCidrRouteEntry OBJECT-TYPE
SYNTAX IpCidrRouteEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"A particular route to a particular destination, under a
ipCidrRouteEntry OBJECT-TYPE SYNTAX IpCidrRouteEntryのマックス-ACCESSのアクセスしやすくないSTATUS推奨しない記述は「aの下の特定の目的地への特定のルート」です。
Haberman Standards Track [Page 15] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[15ページ]RFC4292IP
particular policy."
INDEX {
ipCidrRouteDest,
ipCidrRouteMask,
ipCidrRouteTos,
ipCidrRouteNextHop
}
::= { ipCidrRouteTable 1 }
「特定の方針。」 ipCidrRouteDest、ipCidrRouteMask、ipCidrRouteTos、ipCidrRouteNextHopに索引をつけてください:、:= ipCidrRouteTable1
IpCidrRouteEntry ::= SEQUENCE {
ipCidrRouteDest IpAddress,
ipCidrRouteMask IpAddress,
ipCidrRouteTos Integer32,
ipCidrRouteNextHop IpAddress,
ipCidrRouteIfIndex Integer32,
ipCidrRouteType INTEGER,
ipCidrRouteProto INTEGER,
ipCidrRouteAge Integer32,
ipCidrRouteInfo OBJECT IDENTIFIER,
ipCidrRouteNextHopAS Integer32,
ipCidrRouteMetric1 Integer32,
ipCidrRouteMetric2 Integer32,
ipCidrRouteMetric3 Integer32,
ipCidrRouteMetric4 Integer32,
ipCidrRouteMetric5 Integer32,
ipCidrRouteStatus RowStatus
}
IpCidrRouteEntry:、:= 系列ipCidrRouteDest IpAddress、ipCidrRouteMask IpAddress、ipCidrRouteTos Integer32、ipCidrRouteNextHop IpAddress、ipCidrRouteIfIndex Integer32、ipCidrRouteType整数、ipCidrRouteProto整数、ipCidrRouteAge Integer32、ipCidrRouteInfo物の識別子、ipCidrRouteNextHopAS Integer32、ipCidrRouteMetric1 Integer32、ipCidrRouteMetric2 Integer32、ipCidrRouteMetric3 Integer32、ipCidrRouteMetric4 Integer32、ipCidrRouteMetric5 Integer32、ipCidrRouteStatus RowStatus
ipCidrRouteDest OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The destination IP address of this route.
ipCidrRouteDest OBJECT-TYPE SYNTAX IpAddressマックス-ACCESS書き込み禁止STATUSは「この送付先IPアドレスは発送する」記述を非難しました。
This object may not take a Multicast (Class D) address
value.
この物はMulticast(クラスD)にアドレス値を取らないかもしれません。
Any assignment (implicit or otherwise) of an instance
of this object to a value x must be rejected if the
bitwise logical-AND of x with the value of the
corresponding instance of the ipCidrRouteMask object is
not equal to x."
::= { ipCidrRouteEntry 1 }
「この物の例における値xへの(暗黙かそうではありません)のどんな課題も拒絶しなければならない、物が等しくないipCidrRouteMaskの対応する例の値があるxの論理的なAND x.をbitwiseする、」 ::= ipCidrRouteEntry1
ipCidrRouteMask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
ipCidrRouteMask OBJECT-TYPE SYNTAX IpAddressマックス-ACCESS書き込み禁止
Haberman Standards Track [Page 16] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[16ページ]RFC4292IP
STATUS deprecated
DESCRIPTION
"Indicate the mask to be logical-ANDed with the
destination address before being compared to the value
in the ipCidrRouteDest field. For those systems that
do not support arbitrary subnet masks, an agent
constructs the value of the ipCidrRouteMask by
reference to the IP Address Class.
STATUSの推奨しない記述は「ipCidrRouteDest分野で値と比べる前にマスクが送付先アドレスがある論理的なANDedであることを示します」。 任意のサブネットマスクを支えないそれらのシステムのために、エージェントはIP Address Classの参照でipCidrRouteMaskの値を構成します。
Any assignment (implicit or otherwise) of an instance
of this object to a value x must be rejected if the
bitwise logical-AND of x with the value of the
corresponding instance of the ipCidrRouteDest object is
not equal to ipCidrRouteDest."
::= { ipCidrRouteEntry 2 }
「この物の例における値xへの(暗黙かそうではありません)のどんな課題も拒絶しなければならない、物が等しくないipCidrRouteDestの対応する例の値があるxの論理的なAND ipCidrRouteDestをbitwiseする、」 ::= ipCidrRouteEntry2
-- The following convention is included for specification -- of TOS Field contents. At this time, the Host Requirements -- and the Router Requirements documents disagree on the width -- of the TOS field. This mapping describes the Router -- Requirements mapping, and leaves room to widen the TOS field -- without impact to fielded systems.
-- 以下のコンベンションはTOS Fieldコンテンツの仕様のために含まれています。 このとき、Host Requirements、およびRouter RequirementsドキュメントはTOS分野の幅について意見が異なります。 このマッピングには、システムを戦闘配置につけるために、要件が写像されて、Routerについて説明して、衝撃なしでTOS分野を広くする余地があります。
ipCidrRouteTos OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The policy specifier is the IP TOS Field. The encoding
of IP TOS is as specified by the following convention.
Zero indicates the default path if no more specific
policy applies.
ipCidrRouteTos OBJECT-TYPE SYNTAX Integer32(0 .2147483647)マックス-ACCESS書き込み禁止STATUSは記述を非難しました。「方針特許説明書の作成書はIP TOS Fieldです」。 以下のコンベンションによって指定されるようにIP TOSのコード化があります。 それ以上の特定保険証券が全く適用されないなら、ゼロはデフォルト経路を示します。
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | |
| PRECEDENCE | TYPE OF SERVICE | 0 |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | 先行| サービスのタイプ| 0 | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+
IP TOS IP TOS
Field Policy Field Policy
Contents Code Contents Code
0 0 0 0 ==> 0 0 0 0 1 ==> 2
0 0 1 0 ==> 4 0 0 1 1 ==> 6
0 1 0 0 ==> 8 0 1 0 1 ==> 10
0 1 1 0 ==> 12 0 1 1 1 ==> 14
1 0 0 0 ==> 16 1 0 0 1 ==> 18
1 0 1 0 ==> 20 1 0 1 1 ==> 22
>20>18>16>14>12>10IP TOS IP TOS分野方針分野方針コンテンツコードコンテンツコード0 0 0 0=>0 0 0 0 1=>2 0 0 1 0=>4 0 0 1 1=>6 0 1 0 0=>8 0 1 0 1=0 1 1 0=0 1 1 1=1 0 0 0=1 0 0 1=1 0 1 0=1 0 1 1=>22
Haberman Standards Track [Page 17] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[17ページ]RFC4292IP
1 1 0 0 ==> 24 1 1 0 1 ==> 26
1 1 1 0 ==> 28 1 1 1 1 ==> 30"
::= { ipCidrRouteEntry 3 }
>28>26>24 1 1 0 0=1 1 0 1=1 1 1 0=1 1 1 1=>、30インチ:、:= ipCidrRouteEntry3
ipCidrRouteNextHop OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"On remote routes, the address of the next system en
route; Otherwise, 0.0.0.0."
::= { ipCidrRouteEntry 4 }
ipCidrRouteNextHop OBJECT-TYPE SYNTAX IpAddressマックス-ACCESS書き込み禁止STATUSは「リモートルート、途中次のシステムのアドレス」で記述を非難しました。 「そうでなければ、0.0 .0 .0インチ。 ::= ipCidrRouteEntry4
ipCidrRouteIfIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"The ifIndex value that identifies the local interface
through which the next hop of this route should be
reached."
DEFVAL { 0 }
::= { ipCidrRouteEntry 5 }
ipCidrRouteIfIndex OBJECT-TYPE SYNTAX Integer32マックス-ACCESSはSTATUSの推奨しない記述を読書して作成します。「このルートの次のホップに達するべきである局所界面を特定するifIndex値。」 DEFVAL0:、:= ipCidrRouteEntry5
ipCidrRouteType OBJECT-TYPE
SYNTAX INTEGER {
other (1), -- not specified by this MIB
reject (2), -- route that discards traffic
local (3), -- local interface
remote (4) -- remote destination
}
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"The type of route. Note that local(3) refers to a
route for which the next hop is the final destination;
remote(4) refers to a route for which the next hop is
not the final destination.
{他の(1)--このMIB廃棄物(2)(交通ローカル(3)を捨てるルート)によって地方で指定されないで、リモート(4)を連結してください--遠く離れた目的地}というipCidrRouteType OBJECT-TYPE SYNTAX INTEGERマックス-ACCESSはSTATUSの推奨しない記述を読書して作成します。「ルートのタイプ。」 地方の(3)が次のホップが最終的な目的地であるルートを示すことに注意してください。 リモート(4)は次のホップが最終的な目的地でないルートを示します。
Routes that do not result in traffic forwarding or
rejection should not be displayed, even if the
implementation keeps them stored internally.
交通推進か拒絶をもたらさないルートを表示するべきではありません、実現が、内部的にそれらに格納し続けても。
reject (2) refers to a route that, if matched,
discards the message as unreachable. This is used in
some protocols as a means of correctly aggregating
routes."
::= { ipCidrRouteEntry 6 }
廃棄物(2)は合わせられているなら手の届かないとしてメッセージを捨てるルートを示します。 「これは正しくルートに集める手段としていくつかのプロトコルに使用されます。」 ::= ipCidrRouteEntry6
Haberman Standards Track [Page 18] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[18ページ]RFC4292IP
ipCidrRouteProto OBJECT-TYPE
SYNTAX INTEGER {
other (1), -- not specified
local (2), -- local interface
netmgmt (3), -- static route
icmp (4), -- result of ICMP Redirect
ipCidrRouteProto OBJECT-TYPE SYNTAX INTEGER、他の(1)--指定された地方の(2)(局所界面netmgmt(3))スタティックルートicmp(4)でない--ICMP Redirectの結果
-- the following are all dynamic
-- routing protocols
egp (5), -- Exterior Gateway Protocol
ggp (6), -- Gateway-Gateway Protocol
hello (7), -- FuzzBall HelloSpeak
rip (8), -- Berkeley RIP or RIP-II
isIs (9), -- Dual IS-IS
esIs (10), -- ISO 9542
ciscoIgrp (11), -- Cisco IGRP
bbnSpfIgp (12), -- BBN SPF IGP
ospf (13), -- Open Shortest Path First
bgp (14), -- Border Gateway Protocol
idpr (15), -- InterDomain Policy Routing
ciscoEigrp (16) -- Cisco EIGRP
}
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The routing mechanism via which this route was learned.
Inclusion of values for gateway routing protocols is
not intended to imply that hosts should support those
protocols."
::= { ipCidrRouteEntry 7 }
-- 以下、すべての動力--ルーティング・プロトコルegp(5)--外のゲートウェイプロトコルggp(6)ゲートウェイゲートウェイプロトコルの(7)--FuzzBall HelloSpeak裂け目(8)--こんにちは、バークレーRIPか(RIP-II isIs(9))が二元的である、-、ciscoIgrp(11)--コクチマスIGRP bbnSpfIgp(12)--BBN SPF IGP ospf(13)--開いているShortest Path First bgp(14)--ボーダ・ゲイトウェイ・プロトコルidpr(15)--InterDomain Policyルート設定ciscoEigrp(16)--ISO esIs(10)--9542シスコEIGRP マックス-ACCESS書き込み禁止STATUSは記述を非難しました。「を通したこのルートが学習されたルーティングメカニズム。」 「ゲートウェイルーティング・プロトコルのための値の包含が、ホストがそれらのプロトコルをサポートするべきであるのを含意することを意図しません。」 ::= ipCidrRouteEntry7
ipCidrRouteAge OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The number of seconds since this route was last updated
or otherwise determined to be correct. Note that no
semantics of `too old' can be implied, except through
knowledge of the routing protocol by which the route
was learned."
DEFVAL { 0 }
::= { ipCidrRouteEntry 8 }
ipCidrRouteAge OBJECT-TYPE SYNTAX Integer32マックス-ACCESS書き込み禁止STATUSは記述を非難しました。「このルート以来の秒数は、アップデートしたか、または正しいことを別の方法で決定しました」。 「ルートが学習されたルーティング・プロトコルに関する知識を除いて、'古過ぎること'の意味論を全く含意できないことに注意してください。」 DEFVAL0:、:= ipCidrRouteEntry8
ipCidrRouteInfo OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
ipCidrRouteInfo OBJECT-TYPE SYNTAX OBJECT IDENTIFIERマックス-ACCESSは読書して作成します。
Haberman Standards Track [Page 19] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[19ページ]RFC4292IP
STATUS deprecated
DESCRIPTION
"A reference to MIB definitions specific to the
particular routing protocol that is responsible for
this route, as determined by the value specified in the
route's ipCidrRouteProto value. If this information is
not present, its value should be set to the OBJECT
IDENTIFIER { 0 0 }, which is a syntactically valid
object identifier, and any implementation conforming to
ASN.1 and the Basic Encoding Rules must be able to
generate and recognize this value."
::= { ipCidrRouteEntry 9 }
STATUSは「値で決定するようにこのルートに原因となる特定のルーティング・プロトコルに特定のMIB定義の参照はルートのipCidrRouteProto値で指定した」記述を非難しました。 「この情報が存在していないなら、値がシンタクス上有効な物の識別子であるOBJECT IDENTIFIER0 0に設定されるべきであり、ASN.1とBasic Encoding Rulesに従うどんな実現も、この値を発生して、認識できなければなりません。」 ::= ipCidrRouteEntry9
ipCidrRouteNextHopAS OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"The Autonomous System Number of the Next Hop. The
semantics of this object are determined by the routing-
protocol specified in the route's ipCidrRouteProto
value. When this object is unknown or not relevant, its
value should be set to zero."
DEFVAL { 0 }
::= { ipCidrRouteEntry 10 }
ipCidrRouteNextHopAS OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「次の自律システム番号は飛び越す」STATUSの推奨しない記述を読書して作成します。 この物の意味論はルートのipCidrRouteProto値で指定されたルーティングプロトコルで決定します。 「この物が未知である、または関連していないとき、値はゼロに設定されるべきです。」 DEFVAL0:、:= ipCidrRouteEntry10
ipCidrRouteMetric1 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"The primary routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { ipCidrRouteEntry 11 }
ipCidrRouteMetric1 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法の第一のルーティングは発送する」STATUSの推奨しない記述を読書して作成します。 これほどメートル法の意味論はルートのipCidrRouteProto値で指定されたルーティングプロトコルで決定します。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL-1:、:= ipCidrRouteEntry11
ipCidrRouteMetric2 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipCidrRouteProto
value. If this metric is not used, its value should be
ipCidrRouteMetric2 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法の迂回中継は発送する」STATUSの推奨しない記述を読書して作成します。 これほどメートル法の意味論はルートのipCidrRouteProto値で指定されたルーティングプロトコルで決定します。 これほどメートル法であることが、使用されていて、値がそうあるべきであるということでないなら
Haberman Standards Track [Page 20] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[20ページ]RFC4292IP
set to -1."
DEFVAL { -1 }
::= { ipCidrRouteEntry 12 }
「-1にセットしてください。」 DEFVAL-1:、:= ipCidrRouteEntry12
ipCidrRouteMetric3 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { ipCidrRouteEntry 13 }
ipCidrRouteMetric3 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法の迂回中継は発送する」STATUSの推奨しない記述を読書して作成します。 これほどメートル法の意味論はルートのipCidrRouteProto値で指定されたルーティングプロトコルで決定します。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL-1:、:= ipCidrRouteEntry13
ipCidrRouteMetric4 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { ipCidrRouteEntry 14 }
ipCidrRouteMetric4 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法の迂回中継は発送する」STATUSの推奨しない記述を読書して作成します。 これほどメートル法の意味論はルートのipCidrRouteProto値で指定されたルーティングプロトコルで決定します。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL-1:、:= ipCidrRouteEntry14
ipCidrRouteMetric5 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipCidrRouteProto
value. If this metric is not used, its value should be
set to -1."
DEFVAL { -1 }
::= { ipCidrRouteEntry 15 }
ipCidrRouteMetric5 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法の迂回中継は発送する」STATUSの推奨しない記述を読書して作成します。 これほどメートル法の意味論はルートのipCidrRouteProto値で指定されたルーティングプロトコルで決定します。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL-1:、:= ipCidrRouteEntry15
ipCidrRouteStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
ipCidrRouteStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSはSTATUSの推奨しない記述を読書して作成します。
Haberman Standards Track [Page 21] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[21ページ]RFC4292IP
"The row status variable, used according to row
installation and removal conventions."
::= { ipCidrRouteEntry 16 }
「列のインストールと取り外しコンベンションによると、可変で、中古の列の状態。」 ::= ipCidrRouteEntry16
-- compliance statements
-- 承諾声明
ipForwardCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"The compliance statement for SNMPv2 entities that
implement the ipForward MIB.
ipForwardCompliance MODULE-COMPLIANCE STATUSは記述を非難しました。「ipForward MIBを実行するSNMPv2実体のための承諾声明。」
This compliance statement has been deprecated and
replaced with ipForwardFullCompliance and
ipForwardReadOnlyCompliance."
「この承諾声明をipForwardFullComplianceとipForwardReadOnlyComplianceに非難して、取り替えました。」
MODULE -- this module
MANDATORY-GROUPS { ipForwardCidrRouteGroup }
MODULE--このモジュールMANDATORY-GROUPSipForwardCidrRouteGroup
::= { ipForwardCompliances 1 }
::= ipForwardCompliances1
-- units of conformance
-- ユニットの順応
ipForwardCidrRouteGroup OBJECT-GROUP
OBJECTS { ipCidrRouteNumber,
ipCidrRouteDest, ipCidrRouteMask, ipCidrRouteTos,
ipCidrRouteNextHop, ipCidrRouteIfIndex,
ipCidrRouteType, ipCidrRouteProto, ipCidrRouteAge,
ipCidrRouteInfo,ipCidrRouteNextHopAS,
ipCidrRouteMetric1, ipCidrRouteMetric2,
ipCidrRouteMetric3, ipCidrRouteMetric4,
ipCidrRouteMetric5, ipCidrRouteStatus
}
STATUS deprecated
DESCRIPTION
"The CIDR Route Table.
ipForwardCidrRouteGroup OBJECT-GROUP OBJECTS、ipCidrRouteNumber、ipCidrRouteDest、ipCidrRouteMask、ipCidrRouteTos、ipCidrRouteNextHop、ipCidrRouteIfIndex、ipCidrRouteType、ipCidrRouteProto、ipCidrRouteAge、ipCidrRouteInfo、ipCidrRouteNextHopAS、ipCidrRouteMetric1、ipCidrRouteMetric2、ipCidrRouteMetric3、ipCidrRouteMetric4、ipCidrRouteMetric5、STATUSが非難したipCidrRouteStatus、「CIDRルートはテーブルの上に置く」記述。
This group has been deprecated and replaced with
inetForwardCidrRouteGroup."
::= { ipForwardGroups 3 }
「このグループをinetForwardCidrRouteGroupに非難して、取り替えました。」 ::= ipForwardGroups3
-- Obsoleted Definitions - Objects
-- 時代遅れにされた定義--物
ipForwardNumber OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
ipForwardNumber OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの時代遅れの記述
Haberman Standards Track [Page 22] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[22ページ]RFC4292IP
"The number of current ipForwardTable entries that are
not invalid."
::= { ipForward 1 }
「無効でない現在のipForwardTableエントリーの数。」 ::= ipForward1
-- IP Forwarding Table
-- IP推進テーブル
-- The IP Forwarding Table obsoletes and replaces the ipRoute -- Table current in MIB-I and MIB-II. It adds knowledge of -- the autonomous system of the next hop, multiple next hop -- support, and policy routing support.
-- IP Forwarding TableはipRouteを時代遅れにして、取り替えます--MIB-IとMIB-IIのテーブル電流。 それは--次のホップ、次の複数のホップの自律システム--サポート、および方針ルーティングサポートに関する知識を加えます。
ipForwardTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpForwardEntry
MAX-ACCESS not-accessible
STATUS obsolete
DESCRIPTION
"This entity's IP Routing table."
REFERENCE
"RFC 1213 Section 6.6, The IP Group"
::= { ipForward 2 }
ipForwardTable OBJECT-TYPE SYNTAX SEQUENCE OF IpForwardEntryのマックス-ACCESSのアクセスしやすくないSTATUSは「この実体のIPルート設定はテーブルの上に置く」記述を時代遅れにします。 「RFC1213部6.6、IPグループ」という参照:、:= ipForward2
ipForwardEntry OBJECT-TYPE
SYNTAX IpForwardEntry
MAX-ACCESS not-accessible
STATUS obsolete
DESCRIPTION
"A particular route to a particular destination, under a
particular policy."
INDEX {
ipForwardDest,
ipForwardProto,
ipForwardPolicy,
ipForwardNextHop
}
::= { ipForwardTable 1 }
ipForwardEntry OBJECT-TYPE SYNTAX IpForwardEntryのマックス-ACCESSのアクセスしやすくないSTATUSは記述を時代遅れにします。「特定の方針の下の特定の目的地への特定のルート。」 ipForwardDest、ipForwardProto、ipForwardPolicy、ipForwardNextHopに索引をつけてください:、:= ipForwardTable1
IpForwardEntry ::= SEQUENCE {
ipForwardDest IpAddress,
ipForwardMask IpAddress,
ipForwardPolicy Integer32,
ipForwardNextHop IpAddress,
ipForwardIfIndex Integer32,
ipForwardType INTEGER,
ipForwardProto INTEGER,
ipForwardAge Integer32,
ipForwardInfo OBJECT IDENTIFIER,
ipForwardNextHopAS Integer32,
ipForwardMetric1 Integer32,
IpForwardEntry:、:= 系列、ipForwardDest IpAddress、ipForwardMask IpAddress、ipForwardPolicy Integer32、ipForwardNextHop IpAddress、ipForwardIfIndex Integer32、ipForwardType整数、ipForwardProto整数、ipForwardAge Integer32、ipForwardInfo物の識別子、ipForwardNextHopAS Integer32、ipForwardMetric1 Integer32
Haberman Standards Track [Page 23] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[23ページ]RFC4292IP
ipForwardMetric2 Integer32,
ipForwardMetric3 Integer32,
ipForwardMetric4 Integer32,
ipForwardMetric5 Integer32
}
ipForwardMetric2 Integer32、ipForwardMetric3 Integer32、ipForwardMetric4 Integer32、ipForwardMetric5 Integer32
ipForwardDest OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The destination IP address of this route. An entry
with a value of 0.0.0.0 is considered a default route.
ipForwardDest OBJECT-TYPE SYNTAX IpAddressマックス-ACCESS書き込み禁止STATUSは「この送付先IPアドレスは発送する」記述を時代遅れにします。 値があるエントリー、0.0 .0 .0 デフォルトルートであると考えられます。
This object may not take a Multicast (Class D) address
value.
この物はMulticast(クラスD)にアドレス値を取らないかもしれません。
Any assignment (implicit or otherwise) of an instance
of this object to a value x must be rejected if the
bitwise logical-AND of x with the value of the
corresponding instance of the ipForwardMask object is
not equal to x."
::= { ipForwardEntry 1 }
「この物の例における値xへの(暗黙かそうではありません)のどんな課題も拒絶しなければならない、物が等しくないipForwardMaskの対応する例の値があるxの論理的なAND x.をbitwiseする、」 ::= ipForwardEntry1
ipForwardMask OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"Indicate the mask to be logical-ANDed with the
destination address before being compared to the value
in the ipForwardDest field. For those systems that do
not support arbitrary subnet masks, an agent constructs
the value of the ipForwardMask by reference to the IP
Address Class.
ipForwardMask OBJECT-TYPE SYNTAX IpAddressマックス-ACCESSは時代遅れの記述が「ipForwardDest分野で値と比べる前に目的地がある論理的なANDedがアドレスであったならマスクを示す」STATUSを読書して作成します。 任意のサブネットマスクを支えないそれらのシステムのために、エージェントはIP Address Classの参照でipForwardMaskの値を構成します。
Any assignment (implicit or otherwise) of an instance
of this object to a value x must be rejected if the
bitwise logical-AND of x with the value of the
corresponding instance of the ipForwardDest object is
not equal to ipForwardDest."
DEFVAL { '00000000'H } -- 0.0.0.0
::= { ipForwardEntry 2 }
「この物の例における値xへの(暗黙かそうではありません)のどんな課題も拒絶しなければならない、物が等しくないipForwardDestの対応する例の値があるxの論理的なAND ipForwardDestをbitwiseする、」 DEFVAL'00000000'H--0.0 .0、.0:、:= ipForwardEntry2
-- The following convention is included for specification -- of TOS Field contents. At this time, the Host Requirements -- and the Router Requirements documents disagree on the width -- of the TOS field. This mapping describes the Router
-- 以下のコンベンションはTOS Fieldコンテンツの仕様のために含まれています。 このとき、Host Requirements、およびRouter RequirementsドキュメントはTOS分野の幅について意見が異なります。 このマッピングはRouterについて説明します。
Haberman Standards Track [Page 24] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[24ページ]RFC4292IP
-- Requirements mapping, and leaves room to widen the TOS field -- without impact to fielded systems.
-- 要件マッピング、およびシステムを戦闘配置につける衝撃なしでTOS分野を広くする葉の部屋。
ipForwardPolicy OBJECT-TYPE
SYNTAX Integer32 (0..2147483647)
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The general set of conditions that would cause
the selection of one multipath route (set of
next hops for a given destination) is referred
to as 'policy'.
ipForwardPolicy OBJECT-TYPE SYNTAX Integer32(0 .2147483647)マックス-ACCESS書き込み禁止STATUSは「そうする状態で設定している司令官は(当然のことの目的地への次のホップのセット)が'方針'として参照されるある多重通路ルートの選択を引き起こす」記述を時代遅れにします。
Unless the mechanism indicated by ipForwardProto
specifies otherwise, the policy specifier is
the IP TOS Field. The encoding of IP TOS is as
specified by the following convention. Zero
indicates the default path if no more specific
policy applies.
ipForwardProtoによって示されたメカニズムが別の方法で指定しない場合、方針特許説明書の作成書はIP TOS Fieldです。 以下のコンベンションによって指定されるようにIP TOSのコード化があります。 それ以上の特定保険証券が全く適用されないなら、ゼロはデフォルト経路を示します。
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | |
| PRECEDENCE | TYPE OF SERVICE | 0 |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
+-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | 先行| サービスのタイプ| 0 | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+
IP TOS IP TOS
Field Policy Field Policy
Contents Code Contents Code
0 0 0 0 ==> 0 0 0 0 1 ==> 2
0 0 1 0 ==> 4 0 0 1 1 ==> 6
0 1 0 0 ==> 8 0 1 0 1 ==> 10
0 1 1 0 ==> 12 0 1 1 1 ==> 14
1 0 0 0 ==> 16 1 0 0 1 ==> 18
1 0 1 0 ==> 20 1 0 1 1 ==> 22
1 1 0 0 ==> 24 1 1 0 1 ==> 26
1 1 1 0 ==> 28 1 1 1 1 ==> 30
IP TOS IP TOS分野方針分野、方針内容が>18>16>14>12>10コンテンツコード0 0 0 0=>0 0 0 0 1=>2 0 0 1 0=>4 0 0 1 1=>6 0 1 0 0=>8 0 1 0 1=0 1 1 0=0 1 1 1=1 0 0 0=1 0 0 1=1 0 1 0=>20をコード化する、>28>26>24>22 1 0 1 1=1 1 0 0=1 1 0 1=1 1 1 0=1 1 1 1=>30
Protocols defining 'policy' otherwise must either
define a set of values that are valid for
this object or must implement an integer-instanced
policy table for which this object's
value acts as an index."
::= { ipForwardEntry 3 }
「そうでなければ'方針'を定義するプロトコルは、1セットのこのオブジェクトに、有効な値を定義しなければならないか、またはこのオブジェクトの値がインデックスとして機能する整数で例証された方針テーブルを実装しなければなりません。」 ::= ipForwardEntry3
ipForwardNextHop OBJECT-TYPE
ipForwardNextHopオブジェクト・タイプ
Haberman Standards Track [Page 25] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[25ページ]RFC4292IP
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"On remote routes, the address of the next system en
route; otherwise, 0.0.0.0."
::= { ipForwardEntry 4 }
SYNTAX IpAddressマックス-ACCESS書き込み禁止STATUSは「リモートルート、途中次のシステムのアドレス」で記述を時代遅れにします。 「そうでなければ、0.0 .0 .0インチ。 ::= ipForwardEntry4
ipForwardIfIndex OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"The ifIndex value that identifies the local interface
through which the next hop of this route should be
reached."
DEFVAL { 0 }
::= { ipForwardEntry 5 }
ipForwardIfIndex OBJECT-TYPE SYNTAX Integer32マックス-ACCESSはSTATUSの時代遅れの記述を読書して作成します。「このルートの次のホップに達するべきである局所界面を特定するifIndex値。」 DEFVAL0:、:= ipForwardEntry5
ipForwardType OBJECT-TYPE
SYNTAX INTEGER {
other (1), -- not specified by this MIB
invalid (2), -- logically deleted
local (3), -- local interface
remote (4) -- remote destination
}
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"The type of route. Note that local(3) refers to a
route for which the next hop is the final destination;
remote(4) refers to a route for which the next hop is
not the final destination.
ipForwardType OBJECT-TYPE SYNTAX INTEGERの他の(1)の、そして、遠く離れたこのMIB病人(2)--論理的に削除されたローカル(3)--局所界面リモートな(4)によって指定されないで、目的地マックス-ACCESSはSTATUSの時代遅れの記述を読書して作成します。「ルートのタイプ。」 地方の(3)が次のホップが最終的な目的地であるルートを示すことに注意してください。 リモート(4)は次のホップが最終的な目的地でないルートを示します。
Setting this object to the value invalid(2) has the
effect of invalidating the corresponding entry in the
ipForwardTable object. That is, it effectively
disassociates the destination identified with said
entry from the route identified with said entry. It is
an implementation-specific matter as to whether the
agent removes an invalidated entry from the table.
Accordingly, management stations must be prepared to
receive tabular information from agents that
corresponds to entries not currently in use. Proper
interpretation of such entries requires examination of
the relevant ipForwardType object."
DEFVAL { invalid }
::= { ipForwardEntry 6 }
値の病人(2)にこのオブジェクトを設定するのにおいて、ipForwardTableオブジェクトで対応するエントリーを無効にするという効果があります。 事実上、すなわち、それは前述のエントリーと同一視されたルートから前述のエントリーと同一視された目的地を分離します。 それはエージェントがテーブルから無効にされたエントリーを取り除くかどうかに関する実装特有の問題です。 それに従って、エージェントからの現在使用中でないエントリーに対応する表情報を受け取るように管理局を準備しなければなりません。 「そのようなエントリーの適切な解釈は関連ipForwardTypeオブジェクトの試験を必要とします。」 DEFVAL病人:、:= ipForwardEntry6
Haberman Standards Track [Page 26] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[26ページ]RFC4292IP
ipForwardProto OBJECT-TYPE
SYNTAX INTEGER {
other (1), -- not specified
local (2), -- local interface
netmgmt (3), -- static route
icmp (4), -- result of ICMP Redirect
ipForwardProto OBJECT-TYPE SYNTAX INTEGER、他の(1)--指定された地方の(2)(局所界面netmgmt(3))スタティックルートicmp(4)でない--ICMP Redirectの結果
-- the following are all dynamic
-- routing protocols
egp (5), -- Exterior Gateway Protocol
ggp (6), -- Gateway-Gateway Protocol
hello (7), -- FuzzBall HelloSpeak
rip (8), -- Berkeley RIP or RIP-II
is-is (9), -- Dual IS-IS
es-is (10), -- ISO 9542
ciscoIgrp (11), -- Cisco IGRP
bbnSpfIgp (12), -- BBN SPF IGP
ospf (13), -- Open Shortest Path First
bgp (14), -- Border Gateway Protocol
idpr (15) -- InterDomain Policy Routing
}
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The routing mechanism via which this route was learned.
Inclusion of values for gateway routing protocols is
not intended to imply that hosts should support those
protocols."
::= { ipForwardEntry 7 }
-- (7)--FuzzBall HelloSpeak裂け目(8)--こんにちは、プロトコルegp(5)--外のゲートウェイプロトコルggp(6)--ゲートウェイゲートウェイプロトコルバークレーRIPかRIP-IIを発送して、以下がすべてダイナミックである、-、(9)--、二元的である、-、es存在、(10)、--ISO9542ciscoIgrp(11)--コクチマスIGRP bbnSpfIgp(12)--BBN SPF IGP ospf(13)--Shortest Path First bgp(14)--ボーダ・ゲイトウェイ・プロトコルidpr(15)--InterDomain Policyルート設定を開いてください マックス-ACCESS書き込み禁止STATUSは記述を時代遅れにします。「を通したこのルートが学習されたルーティングメカニズム。」 「ゲートウェイルーティング・プロトコルのための値の包含が、ホストがそれらのプロトコルをサポートするべきであるのを含意することを意図しません。」 ::= ipForwardEntry7
ipForwardAge OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The number of seconds since this route was last updated
or otherwise determined to be correct. Note that no
semantics of `too old' can be implied except through
knowledge of the routing protocol by which the route
was learned."
DEFVAL { 0 }
::= { ipForwardEntry 8 }
ipForwardAge OBJECT-TYPE SYNTAX Integer32マックス-ACCESS書き込み禁止STATUSは記述を時代遅れにします。「このルート以来の秒数は、アップデートしたか、または正しいことを別の方法で決定しました」。 「ルートが学習されたルーティング・プロトコルに関する知識以外に、'古過ぎること'の意味論を全く含意できないことに注意してください。」 DEFVAL0:、:= ipForwardEntry8
ipForwardInfo OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-create
STATUS obsolete
ipForwardInfo OBJECT-TYPE SYNTAX OBJECT IDENTIFIERマックス-ACCESSは時代遅れでSTATUSを読書して作成します。
Haberman Standards Track [Page 27] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[27ページ]RFC4292IP
DESCRIPTION
"A reference to MIB definitions specific to the
particular routing protocol that is responsible for
this route, as determined by the value specified in the
route's ipForwardProto value. If this information is
not present, its value should be set to the OBJECT
IDENTIFIER { 0 0 }, which is a syntactically valid
object identifier, and any implementation conforming to
ASN.1 and the Basic Encoding Rules must be able to
generate and recognize this value."
::= { ipForwardEntry 9 }
「値で決定するようにこのルートに原因となる特定のルーティング・プロトコルに特定のMIB定義の参照はルートのipForwardProto値で指定した」記述。 「この情報が存在していないなら、値がシンタクス上有効なオブジェクト識別子であるOBJECT IDENTIFIER0 0に設定されるべきであり、ASN.1とBasic Encoding Rulesに従うどんな実装も、この値を生成して、認識できなければなりません。」 ::= ipForwardEntry9
ipForwardNextHopAS OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"The Autonomous System Number of the Next Hop. When
this is unknown or not relevant to the protocol
indicated by ipForwardProto, zero."
DEFVAL { 0 }
::= { ipForwardEntry 10 }
ipForwardNextHopAS OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「次の自律システム番号は飛び越す」STATUSの時代遅れの記述を読書して作成します。 「これがipForwardProto、ゼロによって示されたプロトコルに未知である、または関連していないとき。」 DEFVAL0:、:= ipForwardEntry10
ipForwardMetric1 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"The primary routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipForwardProto value.
If this metric is not used, its value should be set to
-1."
DEFVAL { -1 }
::= { ipForwardEntry 11 }
ipForwardMetric1 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法のプライマリルーティングは発送する」STATUSの時代遅れの記述を読書して作成します。 これほどメートル法の意味論はルートのipForwardProto値で指定されたルーティングプロトコルで決定します。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL-1:、:= ipForwardEntry11
ipForwardMetric2 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipForwardProto value.
If this metric is not used, its value should be set to
-1."
DEFVAL { -1 }
::= { ipForwardEntry 12 }
ipForwardMetric2 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法の迂回中継は発送する」STATUSの時代遅れの記述を読書して作成します。 これほどメートル法の意味論はルートのipForwardProto値で指定されたルーティングプロトコルで決定します。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL-1:、:= ipForwardEntry12
Haberman Standards Track [Page 28] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[28ページ]RFC4292IP
ipForwardMetric3 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipForwardProto value.
If this metric is not used, its value should be set to
-1."
DEFVAL { -1 }
::= { ipForwardEntry 13 }
ipForwardMetric3 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法の迂回中継は発送する」STATUSの時代遅れの記述を読書して作成します。 これほどメートル法の意味論はルートのipForwardProto値で指定されたルーティングプロトコルで決定します。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL-1:、:= ipForwardEntry13
ipForwardMetric4 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipForwardProto value.
If this metric is not used, its value should be set to
-1."
DEFVAL { -1 }
::= { ipForwardEntry 14 }
ipForwardMetric4 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法の迂回中継は発送する」STATUSの時代遅れの記述を読書して作成します。 これほどメートル法の意味論はルートのipForwardProto値で指定されたルーティングプロトコルで決定します。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL-1:、:= ipForwardEntry14
ipForwardMetric5 OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS obsolete
DESCRIPTION
"An alternate routing metric for this route. The
semantics of this metric are determined by the routing-
protocol specified in the route's ipForwardProto value.
If this metric is not used, its value should be set to
-1."
DEFVAL { -1 }
::= { ipForwardEntry 15 }
ipForwardMetric5 OBJECT-TYPE SYNTAX Integer32マックス-ACCESSは「これにおける、メートル法の迂回中継は発送する」STATUSの時代遅れの記述を読書して作成します。 これほどメートル法の意味論はルートのipForwardProto値で指定されたルーティングプロトコルで決定します。 「これほどメートル法であることが、使用されていて、値が-1に設定されるべきであるということでない、」 DEFVAL-1:、:= ipForwardEntry15
-- Obsoleted Definitions - Groups -- compliance statements
-- 時代遅れにされたDefinitions--グループ--承諾声明
ipForwardOldCompliance MODULE-COMPLIANCE
STATUS obsolete
DESCRIPTION
"The compliance statement for SNMP entities that
implement the ipForward MIB."
ipForwardOldCompliance MODULE-COMPLIANCE STATUSは記述を時代遅れにします。「ipForward MIBを実装するSNMP実体のための承諾声明。」
Haberman Standards Track [Page 29] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[29ページ]RFC4292IP
MODULE -- this module
MANDATORY-GROUPS { ipForwardMultiPathGroup }
MODULE--このモジュールMANDATORY-GROUPSipForwardMultiPathGroup
::= { ipForwardCompliances 2 }
::= ipForwardCompliances2
ipForwardMultiPathGroup OBJECT-GROUP
OBJECTS { ipForwardNumber,
ipForwardDest, ipForwardMask, ipForwardPolicy,
ipForwardNextHop, ipForwardIfIndex, ipForwardType,
ipForwardProto, ipForwardAge, ipForwardInfo,
ipForwardNextHopAS,
ipForwardMetric1, ipForwardMetric2, ipForwardMetric3,
ipForwardMetric4, ipForwardMetric5
}
STATUS obsolete
DESCRIPTION
"IP Multipath Route Table."
::= { ipForwardGroups 2 }
ipForwardMultiPathGroup OBJECT-GROUP OBJECTS、ipForwardNumber、ipForwardDest、ipForwardMask、ipForwardPolicy、ipForwardNextHop、ipForwardIfIndex、ipForwardType、ipForwardProto、ipForwardAge、ipForwardInfo、ipForwardNextHopAS、ipForwardMetric1、ipForwardMetric2、ipForwardMetric3、ipForwardMetric4、STATUSが時代遅れにするipForwardMetric5、記述「IP多重通路ルートテーブル。」 ::= ipForwardGroups2
END
終わり
6. Security Considerations
6. セキュリティ問題
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability:
aがあります。読書して書くことのマックス-ACCESS節でこのMIBモジュールで定義された管理オブジェクトに付番する、そして/または、読書して作成します。 そのようなオブジェクトはいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響がある場合があります。 これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です:
1. The inetCidrRouteTable contains routing and forwarding
information that is critical to the operation of the network
node (especially routers). Allowing unauthenticated write
access to this table can compromise the validity of the
forwarding information.
1. inetCidrRouteTableはネットワーク・ノード(特にルータ)の操作に重要なルーティングと推進情報を含んでいます。 非認証されて、許容して、テーブルが推進情報の正当性に感染することができるこれへのアクセスを書いてください。
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability:
このMIBモジュール(すなわち、アクセスしやすくないのを除いたマックス-ACCESSがあるオブジェクト)によるいくつかの読み込み可能なオブジェクトがいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 SNMPを通してネットワークの上にそれらを送るとき、その結果、GET、そして/または、これらのオブジェクトへのNOTIFYアクセスさえ制御して、ことによるとこれらのオブジェクトの値を暗号化するのさえ重要です。 これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です:
1. The inetCidrRouteTable contains routing and forwarding
information that can be used to compromise a network.
1. inetCidrRouteTableはネットワークに感染するのに使用できるルーティングと推進情報を含んでいます。
Haberman Standards Track [Page 30] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[30ページ]RFC4292IP
Specifically, this table can be used to construct a map of the
network in preparation for a denial-of-service attack on the
network infrastructure.
明確に、ネットワークインフラにおけるサービス不能攻撃に備えてネットワークの地図を構成するのにこのテーブルを使用できます。
2. The inetCidrRouteProto object identifies the routing protocols
in use within a network. This information can be used to
determine how a denial-of-service attack should be launched.
2. inetCidrRouteProtoオブジェクトはネットワークの中で使用中のルーティング・プロトコルを特定します。 サービス不能攻撃がどのように着手されるべきであるかを決定するのにこの情報を使用できます。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
SNMPv3の前のSNMPバージョンは十分な安全性を含んでいませんでした。 ネットワーク自体が安全であっても(例えば、IPSecを使用するのによる)、その時でさえ、アクセスとGET/SET(読むか、変える、作成する、または削除する)へのオブジェクトが安全なネットワークにこのMIBモジュールでだれに許容されているかに関してコントロールが全くありません。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは([RFC3410]を見てください、セクション8)、RECOMMENDEDです、SNMPv3の暗号のメカニズム(認証とプライバシーのための)の全面的な支援を含んでいて。
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
さらに、SNMPv3の前のSNMPバージョンの展開はNOT RECOMMENDEDです。 代わりに、それはSNMPv3を配布して、暗号のセキュリティを可能にするRECOMMENDEDです。 そして、このMIBモジュールのインスタンスへのアクセスを与えるSNMP実体が本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために適切に構成されるのを保証するのは、顧客/オペレータ責任です。
7. Changes from RFC 2096
7. RFC2096からの変化
This document obsoletes RFC 2096 in the following ways:
このドキュメントは以下の方法でRFC2096を時代遅れにします:
1. Replaces ipCidrRouteTable with inetCidrRouteTable. This
applies to corresponding objects and conformance statements.
1. ipCidrRouteTableをinetCidrRouteTableに取り替えます。 これは対応するオブジェクトと順応声明に適用されます。
2. Utilizes the InetAddress TC to support IP version-independent
implementations of the forwarding MIB. This gives common
forwarding MIB support for IPv4 and IPv6.
2. 推進MIBのIPのバージョンから独立している実装をサポートするのにInetAddress TCを利用します。 これはIPv4とIPv6の一般的な推進MIBサポートを与えます。
3. Creates a read-only conformance statement to support
implementations that only wish to retrieve data.
3. 実装がデータを検索するというその唯一の願望であるとサポートするために書き込み禁止順応声明を作成します。
4. Creates the inetCidrRouteDiscards object to replace the
deprecated ipRoutingDiscards and ipv6DiscardedRoutes objects.
4. 推奨しないipRoutingDiscardsとipv6DiscardedRoutesオブジェクトを取り替えるためにinetCidrRouteDiscardsオブジェクトを作成します。
The inetCidrRouteTable retains the logical structure of the ipCidrRouteTable in order to allow the easy upgrade of existing IPv4 implementations to the version-independent MIB.
inetCidrRouteTableは、既存のIPv4実装の簡単なアップグレードをバージョンから独立しているMIBに許容するためにipCidrRouteTableの論理構造を保有します。
Haberman Standards Track [Page 31] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[31ページ]RFC4292IP
8. Normative References
8. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、パーキンス、D.、およびJ.Schoenwaelder、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual
Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンス、D.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580, April
1999.
[RFC2580] McCloghrieとK.とパーキンス、D.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2863] McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
2005年2月の[RFC4001]ダニエルとM.とハーバーマンとB.とRouthier、S.とJ.Schoenwaelder、「インターネットネットワーク・アドレスのための原文のコンベンション」RFC4001。
[RFC4293] Routhier, S., Ed., "Management Information Base for the
Internet Protocol (IP), RFC 4293, April 2006.
[RFC4293] Routhier、S.、エド、「インターネットプロトコル(IP)、RFC4293、2006年4月のための管理情報ベース。」
[RTPROTO] IANA, "IP Route Protocol MIB",
http://www.iana.org/assignments/ianaiprouteprotocol-mib,
September 2000.
2000年9月の[RTPROTO]IANA、「IPルートプロトコルMIB」 http://www.iana.org/assignments/ianaiprouteprotocol-mib 。
9. Informative References
9. 有益な参照
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II",
RFC 1213, March 1991.
[RFC1213] McCloghrie、K.、およびM.ローズ、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」、RFC1213、1991年3月。
[RFC1354] Baker, F., "IP Forwarding Table MIB", RFC 1354, July 1992.
F.、「IP推進テーブルMIB」、RFC1354 1992年7月の[RFC1354]ベイカー。
[RFC2011] McCloghrie, K., Editor, "SNMPv2 Management Information Base
for the Internet Protocol using SMIv2", RFC 2011, November
1996.
[RFC2011] McCloghrie、K.、エディタ、「1996年11月にSMIv2"、RFC2011を使用するインターネットプロトコルのためのSNMPv2管理情報ベース。」
[RFC2096] Baker, F., "IP Forwarding Table MIB", RFC 2096, January
1997.
F.、「IP推進テーブルMIB」、RFC2096 1997年1月の[RFC2096]ベイカー。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
[RFC3410] ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、「インターネットの標準の管理フレームワークのための序論と適用性声明」、RFC3410(2002年12月)。
Haberman Standards Track [Page 32] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[32ページ]RFC4292IP
[RFC2465] Haskin, D. and S. Onishi, Management Information Base for
IP Version 6: Textual Conventions and General Group", RFC
2465, December 1998.
[RFC2465] IPバージョン6のためのハスキンとD.とS.鬼石、管理情報ベース: 「原文のコンベンションと一般は分類する」RFC2465、1998年12月。
10. Authors and Acknowledgements
10. 作者と承認
This document was based on RFC 2096 [RFC2096].
このドキュメントはRFC2096[RFC2096]に基づきました。
The following people provided text for this version of the document, or were authors of previous versions:
以下の人々は、ドキュメントのこのバージョンにテキストを提供するか、または旧バージョンの作者でした:
Fred Baker, Cisco Bill Fenner, AT&T Research Brian Haberman, Johns Hopkins University - Applied Physics Laboratory Juergen Schoenwalder, TU Braunschweig Dave Thaler, Microsoft Margaret Wasserman, Thingmagic
フレッド・ベイカー、シスコのビル・フェナー、AT&Tの研究ブライアン・ハーバーマン、ジョーンズ・ホプキンス大学--応用物理研究所ユルゲンSchoenwalder、TUブラウンシュバイクデーヴThaler、マイクロソフトのマーガレット・ワッサーマン、Thingmagic
Dario Accornero, Mark Adam, Qing Li, and Shawn Routhier reviewed the document and provided helpful feedback.
ダリウスAccornero、マーク・アダム、清の李、およびショーンRouthierはドキュメントを再検討して、役立っているフィードバックを提供しました。
Mike Heard provided valuable feedback as the MIB Doctor for this document.
マイクHeardはこのドキュメントのためのMIB医師として有益なフィードバックを提供しました。
Editors' Contact Information
エディタの問い合わせ先
Comments or questions regarding this document should be sent to:
以下のことのためにこのドキュメントに関するコメントか質問を送るべきです。
Brian Haberman Johns Hopkins University - Applied Physics Laboratory Mailstop 17-S442 11100 Johns Hopkins Road Laurel MD, 20723-6099 USA
ブライアンハーバーマンジョーンズ・ホプキンス大学--応用物理研究所Mailstop 17-S442 11100ジョーンズ・ホプキン道路ローレル20723-6099MD(米国)
Phone: +1-443-778-1319 EMail: brian@innovationslab.net
以下に電話をしてください。 +1-443-778-1319 メールしてください: brian@innovationslab.net
Haberman Standards Track [Page 33] RFC 4292 IP Forwarding Table MIB April 2006
2006年4月にテーブルMIBを進めるハーバーマン標準化過程[33ページ]RFC4292IP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Haberman Standards Track [Page 34]
ハーバーマン標準化過程[34ページ]
一覧
スポンサーリンク
