[要約] RFC 7868は、CiscoのEIGRPの拡張版である。EIGRPは内部ゲートウェイルーティングプロトコルであり、大規模なネットワークでの高性能と信頼性を提供することを目的としている。
Independent Submission D. Savage
Request for Comments: 7868 J. Ng
Category: Informational S. Moore
ISSN: 2070-1721 Cisco Systems
D. Slice
Cumulus Networks
P. Paluch
University of Zilina
R. White
LinkedIn
May 2016
Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)
シスコのEnhanced Interior Gateway Routing Protocol（EIGRP）
Abstract
概要
This document describes the protocol design and architecture for Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a routing protocol based on Distance Vector technology. The specific algorithm used is called "DUAL", a Diffusing Update Algorithm as referenced in "Loop-Free Routing Using Diffusing Computations" (Garcia-Luna-Aceves 1993). The algorithm and procedures were researched, developed, and simulated by SRI International.
このドキュメントでは、Enhanced Interior Gateway Routing Protocol（EIGRP）のプロトコル設計とアーキテクチャについて説明します。 EIGRPは、Distance Vectorテクノロジーに基づくルーティングプロトコルです。使用される特定のアルゴリズムは「DUAL」と呼ばれ、「拡散計算を使用したループフリールーティング」（Garcia-Luna-Aceves 1993）で参照されている拡散更新アルゴリズムです。アルゴリズムと手順は、SRI Internationalによって研究、開発、シミュレーションされました。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7868.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7868で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントは、RFCとして公開するためにフォーマットしたり、英語以外の言語に翻訳したりする場合を除き、変更したり、その派生物を作成したりすることはできません。
Table of Contents
目次
1. Introduction ....................................................5
2. Conventions .....................................................5
2.1. Requirements Language ......................................5
2.2. Terminology ................................................5
3. The Diffusing Update Algorithm (DUAL) ...........................9
3.1. Algorithm Description ......................................9
3.2. Route States ..............................................10
3.3. Feasibility Condition .....................................11
3.4. DUAL Message Types ........................................13
3.5. DUAL Finite State Machine (FSM) ...........................13
3.6. DUAL Operation -- Example Topology ........................18
4. EIGRP Packets ..................................................20
4.1. UPDATE Packets ............................................21
4.2. QUERY Packets .............................................21
4.3. REPLY Packets .............................................22
4.4. Exception Handling ........................................22
4.4.1. Active Duration (SIA) ..............................22
4.4.1.1. SIA-QUERY .................................23
4.4.1.2. SIA-REPLY .................................24
5. EIGRP Operation ................................................25
5.1. Finite State Machine ......................................25
5.2. Reliable Transport Protocol ...............................25
5.2.1. Bandwidth on Low-Speed Links .......................32
5.3. Neighbor Discovery/Recovery ...............................32
5.3.1. Neighbor Hold Time .................................32
5.3.2. HELLO Packets ......................................33
5.3.3. UPDATE Packets .....................................33
5.3.4. Initialization Sequence ............................34
5.3.5. Neighbor Formation .................................35
5.3.6. QUERY Packets during Neighbor Formation ............35
5.4. Topology Table ............................................36
5.4.1. Route Management ...................................36
5.4.1.1. Internal Routes ...........................37
5.4.1.2. External Routes ...........................37
5.4.2. Split Horizon and Poison Reverse ...................38
5.4.2.1. Startup Mode ..............................38
5.4.2.2. Advertising Topology Table Change .........39
5.4.2.3. Sending a QUERY/UPDATE ....................39
5.5. EIGRP Metric Coefficients .................................39
5.5.1. Coefficients K1 and K2 .............................40
5.5.2. Coefficient K3 .....................................40
5.5.3. Coefficients K4 and K5 .............................40
5.5.4. Coefficient K6 .....................................41
5.5.4.1. Jitter ....................................41
5.5.4.2. Energy ....................................41
5.6. EIGRP Metric Calculations .................................41
5.6.1. Classic Metrics ....................................41
5.6.1.1. Classic Composite Formulation .............42
5.6.1.2. Cisco Interface Delay Compatibility .......43
5.6.2. Wide Metrics .......................................43
5.6.2.1. Wide Metric Vectors .......................44
5.6.2.2. Wide Metric Conversion Constants ..........45
5.6.2.3. Throughput Calculation ....................45
5.6.2.4. Latency Calculation .......................46
5.6.2.5. Composite Calculation .....................46
6. EIGRP Packet Formats ...........................................46
6.1. Protocol Number ...........................................46
6.2. Protocol Assignment Encoding ..............................47
6.3. Destination Assignment Encoding ...........................47
6.4. EIGRP Communities Attribute ...............................48
6.5. EIGRP Packet Header .......................................49
6.6. EIGRP TLV Encoding Format .................................51
6.6.1. Type Field Encoding ................................52
6.6.2. Length Field Encoding ..............................52
6.6.3. Value Field Encoding ...............................52
6.7. EIGRP Generic TLV Definitions .............................52
6.7.1. 0x0001 - PARAMETER_TYPE ............................53
6.7.2. 0x0002 - AUTHENTICATION_TYPE .......................53
6.7.2.1. 0x02 - MD5 Authentication Type ............54
6.7.2.2. 0x03 - SHA2 Authentication Type ...........54
6.7.3. 0x0003 - SEQUENCE_TYPE .............................54
6.7.4. 0x0004 - SOFTWARE_VERSION_TYPE .....................55
6.7.5. 0x0005 - MULTICAST_SEQUENCE_TYPE ...................55
6.7.6. 0x0006 - PEER_INFORMATION_TYPE .....................55
6.7.7. 0x0007 - PEER_ TERMINATION_TYPE ....................56
6.7.8. 0x0008 - TID_LIST_TYPE .............................56
6.8. Classic Route Information TLV Types .......................57
6.8.1. Classic Flag Field Encoding ........................57
6.8.2. Classic Metric Encoding ............................57
6.8.3. Classic Exterior Encoding ..........................58
6.8.4. Classic Destination Encoding .......................59
6.8.5. IPv4-Specific TLVs .................................59
6.8.5.1. IPv4 INTERNAL_TYPE ........................60
6.8.5.2. IPv4 EXTERNAL_TYPE ........................60
6.8.5.3. IPv4 COMMUNITY_TYPE .......................62
6.8.6. IPv6-Specific TLVs .................................62
6.8.6.1. IPv6 INTERNAL_TYPE ........................63
6.8.6.2. IPv6 EXTERNAL_TYPE ........................63
6.8.6.3. IPv6 COMMUNITY_TYPE .......................65
6.9. Multiprotocol Route Information TLV Types .................66
6.9.1. TLV Header Encoding ................................66
6.9.2. Wide Metric Encoding ...............................67
6.9.3. Extended Metrics ...................................68
6.9.3.1. 0x00 - NoOp ...............................69
6.9.3.2. 0x01 - Scaled Metric ......................70
6.9.3.3. 0x02 - Administrator Tag ..................70
6.9.3.4. 0x03 - Community List .....................71
6.9.3.5. 0x04 - Jitter .............................71
6.9.3.6. 0x05 - Quiescent Energy ...................71
6.9.3.7. 0x06 - Energy .............................72
6.9.3.8. 0x07 - AddPath ............................72
6.9.3.8.1. AddPath with IPv4 Next Hop .....73
6.9.3.8.2. AddPath with IPv6 Next Hop .....74
6.9.4. Exterior Encoding ..................................75
6.9.5. Destination Encoding ...............................76
6.9.6. Route Information ..................................76
6.9.6.1. INTERNAL TYPE .............................76
6.9.6.2. EXTERNAL TYPE .............................76
7. Security Considerations ........................................77
8. IANA Considerations ............................................77
9. References .....................................................77
9.1. Normative References ......................................77
9.2. Informative References ....................................78
Acknowledgments ...................................................79
Authors' Addresses ................................................80
This document describes the Enhanced Interior Gateway Routing Protocol (EIGRP), a routing protocol designed and developed by Cisco Systems, Inc. DUAL, the algorithm used to converge the control plane to a single set of loop-free paths is based on research conducted at SRI International [3]. The Diffusing Update Algorithm (DUAL) is the algorithm used to obtain loop freedom at every instant throughout a route computation [2]. This allows all routers involved in a topology change to synchronize at the same time; the routers not affected by topology changes are not involved in the recalculation. This document describes the protocol that implements these functions.
このドキュメントでは、Cisco Systems、Inc.によって設計および開発されたルーティングプロトコルであるEnhanced Interior Gateway Routing Protocol（EIGRP）について説明します。DUALは、コントロールプレーンを単一のループフリーパスに収束するために使用されるアルゴリズムが、 SRIインターナショナル[3]。 Diffusing Update Algorithm（DUAL）は、ルート計算[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 [1].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [1]で説明されているように解釈されます。
The following is a list of abbreviations and terms used throughout this document:
以下は、このドキュメント全体で使用される略語と用語のリストです。
ACTIVE State: The local state of a route on a router triggered by any event that causes all neighbors providing the current least-cost path to fail the Feasibility Condition check. A route in Active state is considered unusable. During Active state, the router is actively attempting to compute the least-cost loop-free path by explicit coordination with its neighbors using Query and Reply messages.
アクティブ状態：現在の最小コストパスを提供するすべてのネイバーが実現可能性条件のチェックに失敗する原因となるイベントによってトリガーされたルーターのルートのローカル状態。アクティブ状態のルートは使用不可と見なされます。アクティブ状態の間、ルーターはクエリと返信メッセージを使用して、ネイバーと明示的に調整することにより、最小コストのループフリーパスを積極的に計算しようとします。
Address Family Identifier (AFI): Identity of the network-layer protocol reachability information being advertised [12].
アドレスファミリ識別子（AFI）：アドバタイズされているネットワーク層プロトコルの到達可能性情報のID [12]。
Autonomous System (AS): A collection of routers exchanging routes under the control of one or more network administrators on behalf of a single administrative entity.
Autonomous System（AS）：単一の管理エンティティに代わって1人以上のネットワーク管理者の制御下でルートを交換するルーターの集まり。
Base Topology: A routing domain representing a physical (non-virtual) view of the network topology consisting of attached devices and network segments EIGRP uses to form neighbor relationships. Destinations exchanged within the Base Topology are identified with a Topology Identifier value of zero (0).
基本トポロジ：EIGRPがネイバー関係を形成するために使用する接続デバイスとネットワークセグメントで構成されるネットワークトポロジの物理（非仮想）ビューを表すルーティングドメイン。基本トポロジー内で交換される宛先は、ゼロ（0）のトポロジーID値で識別されます。
Computed Distance (CD): Total distance (metric) along a path from the current router to a destination network through a particular neighbor computed using that neighbor's Reported Distance (RD) and the cost of the link between the two routers. Exactly one CD is computed and maintained per the [Destination, Advertising Neighbor] pair.
計算距離（CD）：現在のルーターから宛先ネットワークまでのパスに沿った、その近隣の報告距離（RD）と2つのルーター間のリンクのコストを使用して計算された特定の近隣を通る合計距離（メトリック）。 [Destination、Advertising Neighbor]ペアごとに正確に1つのCDが計算され、維持されます。
CR-Mode Conditionally Received Mode
CR-Mode条件付き受信モード
Diffusing Computation: A distributed computation in which a single starting node commences the computation by delegating subtasks of the computation to its neighbors that may, in turn, recursively delegate sub-subtasks further, including a signaling scheme allowing the starting node to detect that the computation has finished while avoiding false terminations. In DUAL, the task of coordinated updates of routing tables and resulting best path computation is performed as a diffusing computation.
拡散計算：単一の開始ノードが計算のサブタスクを近隣に委任することによって計算を開始する分散計算。次に、サブノードを再帰的に委任し、開始ノードがその計算を検出できるようにするシグナリングスキームを含めます。誤った終了を回避しながら終了しました。 DUALでは、ルーティングテーブルの調整された更新のタスクと、結果として得られる最適なパスの計算は、拡散計算として実行されます。
Diffusing Update Algorithm (DUAL): A loop-free routing algorithm used with distance vectors or link states that provides a diffused computation of a routing table. It works very well in the presence of multiple topology changes with low overhead. The technology was researched and developed at SRI International [3].
拡散更新アルゴリズム（DUAL）：ルーティングテーブルの拡散計算を提供する、距離ベクトルまたはリンク状態で使用されるループのないルーティングアルゴリズム。オーバーヘッドの少ない複数のトポロジー変更がある場合に非常によく機能します。このテクノロジーは、SRI Internationalで研究開発されました[3]。
Downstream Router: A router that is one or more hops away from the router in question in the direction of the destination.
ダウンストリームルーター：問題のルーターから宛先の方向に1ホップ以上離れたルーター。
EIGRP: Enhanced Interior Gateway Routing Protocol.
EIGRP：Enhanced Interior Gateway Routing Protocol。
Feasibility Condition: The Feasibility Condition is a sufficient condition used by a router to verify whether a neighboring router provides a loop-free path to a destination. EIGRP uses the Source Node Condition stating that a neighboring router meets the Feasibility Condition if the neighbor's RD is less than this router's Feasible Distance.
実現可能性条件：実現可能性条件は、ルーターが隣接ルーターが宛先へのループフリーパスを提供しているかどうかを確認するために使用される十分な条件です。 EIGRPは、隣接ルータのRDがこのルータの到達可能距離よりも短い場合、隣接ルータが実現可能条件を満たしていることを示す送信元ノード条件を使用します。
Feasible Distance (FD): Defined as the least-known total metric to a destination from the current router since the last transition from ACTIVE to PASSIVE state. Being effectively a record of the smallest known metric since the last time the network entered the PASSIVE state, the FD is not necessarily a metric of the current best path. Exactly one FD is computed per destination network.
Feasible Distance（FD）：ACTIVEからPASSIVE状態への最後の遷移以降、現在のルーターから宛先への最小既知の総メトリックとして定義されます。 FDは、ネットワークが最後にPASSIVE状態になったときからの最小の既知のメトリックの記録であるため、必ずしも現在の最適パスのメトリックとは限りません。宛先ネットワークごとに正確に1つのFDが計算されます。
Feasible Successor: A neighboring router that meets the Feasibility Condition for a particular destination, hence, providing a guaranteed loop-free path.
フィジブルサクセサ：特定の宛先のフィジビリティ条件を満たし、ループフリーパスが保証された隣接ルータ。
Neighbor/Peer: For a particular router, another router toward which an EIGRP session, also known as an "adjacency", is established. The ability of two routers to become neighbors depends on their mutual connectivity and compatibility of selected EIGRP configuration parameters. Two neighbors with interfaces connected to a common subnet are known as adjacent neighbors. Two neighbors that are multiple hops apart are known as remote neighbors.
ネイバー/ピア：特定のルーターについて、「隣接」とも呼ばれるEIGRPセッションが確立される別のルーター。 2つのルーターがネイバーになる能力は、それらの相互接続と、選択したEIGRP構成パラメーターの互換性によって異なります。共通のサブネットに接続されたインターフェースを持つ2つのネイバーは、隣接ネイバーと呼ばれます。複数のホップが離れている2つのネイバーは、リモートネイバーと呼ばれます。
PASSIVE state: The local state of a route in which at least one neighbor providing the current least-cost path passes the Feasibility Condition check. A route in PASSIVE state is considered usable and not in need of a coordinated re-computation.
パッシブ状態：現在の最小コストパスを提供する少なくとも1つのネイバーが実現可能性条件チェックに合格するルートのローカル状態。パッシブ状態のルートは使用可能と見なされ、調整された再計算は必要ありません。
Network Layer Reachability Information (NLRI): Information a router uses to calculate the global routing table to make routing and forwarding decisions.
ネットワーク層到達可能性情報（NLRI）：ルーターがルーティングと転送の決定を行うためにグローバルルーティングテーブルを計算するために使用する情報。
Reported Distance (RD): For a particular destination, the value representing the router's distance to the destination as advertised in all messages carrying routing information. RD is not equivalent to the current distance of the router to the destination and may be different from it during the process of path re-computation. Exactly one RD is computed and maintained per destination network.
報告距離（RD）：特定の宛先の場合、ルーティング情報を運ぶすべてのメッセージで通知された、宛先までのルーターの距離を表す値。 RDは、ルーターから宛先までの現在の距離と同等ではなく、パスの再計算のプロセス中には異なる場合があります。宛先ネットワークごとに正確に1つのRDが計算され、維持されます。
Sub-Topology: For a given Base Topology, a sub-topology is characterized by an independent set of routers and links in a network for which EIGRP performs an independent path calculation. This allows each sub-topology to implement class-specific topologies to carry class-specific traffic.
サブトポロジ：特定の基本トポロジの場合、サブトポロジは、EIGRPが独立したパス計算を実行するネットワーク内の独立したルーターとリンクのセットによって特徴付けられます。これにより、各サブトポロジはクラス固有のトポロジを実装して、クラス固有のトラフィックを伝送できます。
Successor: For a particular destination, a neighboring router that meets the Feasibility Condition and, at the same time, provides the least-cost path.
後継者：特定の宛先について、実現可能性条件を満たすと同時に、最小コストのパスを提供する隣接ルーター。
Stuck In Active (SIA): A destination that has remained in the ACTIVE State in excess of a predefined time period at the local router (Cisco implements this as 3 minutes).
Stuck In Active（SIA）：ローカルルーターで事前定義された期間を超えてACTIVE状態に留まった宛先（シスコではこれを3分として実装しています）。
Successor-Directed Acyclic Graph (SDAG): For a particular destination, a graph defined by routing table contents of individual routers in the topology, such that nodes of this graph are the routers themselves and a directed edge from router X to router Y exists if and only if router Y is router X's successor. After the network has converged, in the absence of topological changes, SDAG is a tree.
後継者向け非循環グラフ（SDAG）：特定の宛先について、トポロジ内の個々のルーターのルーティングテーブルの内容によって定義されるグラフ。このグラフのノード自体がルーターであり、ルーターXからルーターYへの有向エッジが存在する場合ルータYがルータXの後継である場合のみ。ネットワークが収束した後、トポロジーの変更がない場合、SDAGはツリーになります。
Topology Change / Topology-Change Event: Any event that causes the CD for a destination through a neighbor to be added, modified, or removed. As an example, detecting a link-cost change, receiving any EIGRP message from a neighbor advertising an updated neighbor's RD.
トポロジー変更/トポロジー変更イベント：ネイバーを介して宛先のCDが追加、変更、または削除される原因となるイベント。例として、リンクコストの変更を検出し、更新されたネイバーのRDをアドバタイズするネイバーからEIGRPメッセージを受信します。
Topology Identifier (TID): A number that is used to mark prefixes as belonging to a specific sub-topology.
トポロジ識別子（TID）：プレフィックスを特定のサブトポロジに属するものとしてマークするために使用される番号。
Topology Table: A data structure used by EIGRP to store information about every known destination including, but not limited to, network prefix / prefix length, FD, RD of each neighbor advertising the destination, CD over the corresponding neighbor, and route state.
トポロジテーブル：EIGRPが既知のすべての宛先に関する情報を格納するために使用するデータ構造。これには、ネットワークプレフィックス/プレフィックス長、FD、宛先をアドバタイズする各ネイバーのRD、対応するネイバーを介したCD、ルート状態などが含まれますが、これらに限定されません。
Type, Length, Value (TLV): An encoding format for information elements used in EIGRP messages to exchange information. Each TLV-formatted information element consists of three generic fields: Type identifying the nature of information carried in this element, Length describing the length of the entire TLV triplet, and Value carrying the actual information. The Value field may, itself, be internally structured; this depends on the actual type of the information element. This format allows for extensibility and backward compatibility.
タイプ、長さ、値（TLV）：EIGRPメッセージで情報を交換するために使用される情報要素のエンコード形式。各TLV形式の情報要素は、3つの一般的なフィールドで構成されます。この要素で運ばれる情報の性質を識別するタイプ、TLVトリプレット全体の長さを表す長さ、および実際の情報を運ぶ値。 Valueフィールド自体は、内部的に構造化されている場合があります。これは、情報要素の実際のタイプによって異なります。この形式は、拡張性と下位互換性を可能にします。
Upstream Router: A router that is one or more hops away from the router in question, in the direction of the source of the information.
アップストリームルーター：問題のルーターから情報ソースの方向に1ホップ以上離れたルーター。
VID: VLAN Identifier
VID：VLAN ID
Virtual Routing and Forwarding (VRF): Independent Virtual Private Network (VPN) routing/forwarding tables that coexist within the same router at the same time.
仮想ルーティングおよび転送（VRF）：同じルーター内で同時に共存する独立した仮想プライベートネットワーク（VPN）のルーティング/転送テーブル。
The Diffusing Update Algorithm (DUAL) constructs least-cost paths to all reachable destinations in a network consisting of nodes and edges (routers and links). DUAL guarantees that each constructed path is loop free at every instant including periods of topology changes and network reconvergence. This is accomplished by all routers, which are affected by a topology change, computing the new best path in a coordinated (diffusing) way and using the Feasibility Condition to verify prospective paths for loop freedom. Routers that are not affected by topology changes are not involved in the recalculation. The convergence time with DUAL rivals that of any other existing routing protocol.
拡散更新アルゴリズム（DUAL）は、ノードとエッジ（ルーターとリンク）で構成されるネットワーク内の到達可能なすべての宛先への最小コストパスを構築します。 DUALは、構築された各パスが、トポロジの変更やネットワークの再コンバージェンスの期間を含むすべての瞬間にループしないことを保証します。これは、トポロジ変更の影響を受けるすべてのルーターによって実現され、調整された（拡散する）方法で新しい最適パスを計算し、実現可能性条件を使用して、ループの自由について予想されるパスを検証します。トポロジ変更の影響を受けないルーターは再計算に含まれません。 DUALとのコンバージェンス時間は、他の既存のルーティングプロトコルに匹敵します。
DUAL is used by EIGRP to achieve fast loop-free convergence with little overhead, allowing EIGRP to provide convergence rates comparable, and in some cases better than, most common link state protocols [10]. Only nodes that are affected by a topology change need to propagate and act on information about the topology change, allowing EIGRP to have good scaling properties, reduced overhead, and lower complexity than many other interior gateway protocols.
EIGRPはDUALを使用して、オーバーヘッドがほとんどなく、ループのない高速な収束を実現します。これにより、EIGRPは、最も一般的なリンク状態プロトコルに匹敵する、場合によってはそれより優れた収束レートを提供できます[10]。トポロジー変更の影響を受けるノードのみがトポロジー変更に関する情報を伝達および処理する必要があるため、EIGRPは他の多くの内部ゲートウェイプロトコルよりも優れたスケーリングプロパティ、オーバーヘッドの削減、複雑さの軽減を実現できます。
Distributed routing algorithms are required to propagate information as well as coordinate information among all nodes in the network. Unlike basic Bellman-Ford distance vector protocols that rely on uncoordinated updates when a topology change occurs, DUAL uses a coordinated procedure to involve the affected part of the network into computing a new least-cost path, known as a "diffusing computation". A diffusing computation grows by querying additional routers for their current RD to the affected destination, and it shrinks by receiving replies from them. Unaffected routers send replies immediately, terminating the growth of the diffusing computation over them. These intrinsic properties cause the diffusing computation to self-adjust in scope and terminate as soon as possible.
ネットワーク内のすべてのノード間で情報を伝達するだけでなく、情報を調整するには、分散ルーティングアルゴリズムが必要です。トポロジ変更が発生したときに非協調型更新に依存する基本的なベルマンフォード距離ベクトルプロトコルとは異なり、DUALは協調手順を使用して、ネットワークの影響を受ける部分を「拡散計算」と呼ばれる新しい最小コストパスの計算に関与させます。拡散計算は、影響を受ける宛先への現在のRDについて追加のルーターをクエリすることで拡大し、ルーターからの応答を受信することで縮小します。影響を受けていないルータはすぐに応答を送信し、それらに対する拡散計算の増加を停止します。これらの固有のプロパティにより、拡散計算はスコープ内で自動調整され、できるだけ早く終了します。
One attribute of DUAL is its ability to control the point at which the diffusion of a route calculation terminates by managing the distribution of reachability information through the network.
DUALの1つの属性は、ネットワークを介した到達可能性情報の配布を管理することにより、ルート計算の拡散が終了するポイントを制御する機能です。
Controlling the scope of the diffusing process is accomplished by hiding reachability information through aggregation (summarization), filtering, or other means. This provides the ability to create effective failure domains within a single AS, and allows the network administrator to manage the convergence and processing characteristics of the network.
拡散プロセスの範囲の制御は、集約（要約）、フィルタリング、またはその他の手段を通じて到達可能性情報を非表示にすることによって行われます。これにより、単一のAS内に効果的な障害ドメインを作成する機能が提供され、ネットワーク管理者はネットワークの収束と処理特性を管理できます。
A route to a destination can be in one of two states: PASSIVE or ACTIVE. These states describe whether the route is guaranteed to be both loop free and the shortest available (the PASSIVE state) or whether such a guarantee cannot be given (the ACTIVE state). Consequently, in PASSIVE state, the router does not perform any route recalculation in coordination with its neighbors because no such recalculation is needed.
宛先へのルートは、パッシブまたはアクティブの2つの状態のいずれかになります。これらの状態は、ルートがループフリーであり、利用可能な最短の両方であることが保証されているか（パッシブ状態）、またはそのような保証が与えられないか（アクティブ状態）を示します。その結果、パッシブ状態では、ルーターは近隣のルーターと連携してルートの再計算を実行しません。そのような再計算は必要ないためです。
In ACTIVE state, the router is actively involved in re-computing the least-cost loop-free path in coordination with its neighbors. The state is reevaluated and possibly changed every time a topology change is detected. A topology change is any event that causes the CD to the destination over any neighbor to be added, changed, or removed from EIGRP's topology table.
アクティブ状態では、ルーターは近隣のノードと連携して最小コストのループフリーパスの再計算に積極的に関与しています。状態は再評価され、トポロジの変更が検出されるたびに変更される可能性があります。トポロジ変更とは、EIGRPのトポロジテーブルに対して、ネイバーを介してCDを宛先に追加、変更、または削除するイベントです。
More exactly, the two states are defined as follows:
より正確には、2つの状態は次のように定義されます。
o Passive
o 受動的
A route is considered to be in the Passive state when at least one neighbor that provides the current least-total-cost path passes the Feasibility Condition check that guarantees loop freedom. A route in the PASSIVE state is usable and its next hop is perceived to be a downstream router.
現在の最小総コストパスを提供する少なくとも1つのネイバーがループの自由を保証する実現可能性条件チェックに合格すると、ルートはパッシブ状態であると見なされます。パッシブ状態のルートは使用可能であり、そのネクストホップはダウンストリームルーターであると認識されます。
o Active
o アクティブ
A route is considered to be in the ACTIVE state if neighbors that do not pass the Feasibility Condition check provide lowest-cost path, and therefore the path cannot be guaranteed loop free. A route in the ACTIVE state is considered unusable and this router must coordinate with its neighbors in the search for the new loop-free least-total-cost path.
フィージビリティコンディションチェックに合格しないネイバーが最低コストのパスを提供する場合、ルートはアクティブ状態であると見なされ、そのため、パスのループフリーは保証されません。 ACTIVE状態のルートは使用不可と見なされ、このルーターは、新しいループのない最小総コストパスを検索する際にネイバーと調整する必要があります。
In other words, for a route to be in PASSIVE state, at least one neighbor that provides the least-total-cost path must be a Feasible Successor. Feasible Successors providing the least-total-cost path are also called "successors". For a route to be in PASSIVE state, at least one successor must exist.
つまり、ルートがパッシブ状態になるには、総コストが最小のパスを提供する少なくとも1つのネイバーがフィジブルサクセサーである必要があります。最小総コストパスを提供する実行可能な後継者は、「後継者」とも呼ばれます。ルートがパッシブ状態になるには、少なくとも1つのサクセサーが存在する必要があります。
Conversely, if the path with the least total cost is provided by routers that are not Feasible Successors (and thus not successors), the route is in the ACTIVE state, requiring re-computation.
逆に、総コストが最小のパスが、フィジブルサクセサではない（したがってサクセサではない）ルータによって提供される場合、ルートはアクティブ状態にあり、再計算が必要です。
Notably, for the definition of PASSIVE and ACTIVE states, it does not matter if there are Feasible Successors providing a worse-than-least-total-cost path. While these neighbors are guaranteed to provide a loop-free path, that path is potentially not the shortest available.
特に、パッシブ状態とアクティブ状態の定義では、総コストが最も低いパスを提供するフィジブルサクセサが存在するかどうかは重要ではありません。これらのネイバーはループのないパスを提供することが保証されていますが、そのパスは利用可能な最短距離ではない可能性があります。
The fact that the least-total-cost path can be provided by a neighbor that fails the Feasibility Condition check may not be intuitive. However, such a situation can occur during topology changes when the current least-total-cost path fails and the next-least-total-cost path traverses a neighbor that is not a Feasible Successor.
実現可能性条件のチェックに失敗したネイバーが最小総コストパスを提供できるという事実は、直感的ではない場合があります。ただし、トポロジの変更中に、現在の最小総コストパスに障害が発生し、次の最小総コストパスがフィジブルサクセサではないネイバーを通過する場合に、このような状況が発生する可能性があります。
While a router has a route in the ACTIVE state, it must not change its successor (i.e., modify the current SDAG) nor modify its own Feasible Distance or RD until the route enters the PASSIVE state again. Any updated information about this route received during ACTIVE state is reflected only in CDs. Any updates to the successor, FD, and RD are postponed until the route returns to PASSIVE state. The state transitions from PASSIVE to ACTIVE and from ACTIVE to PASSIVE are controlled by the DUAL FSM and are described in detail in Section 3.5.
ルーターにアクティブ状態のルートがある間は、ルートが再びパッシブ状態になるまで、後続ノードを変更（つまり、現在のSDAGを変更）したり、自身の実行可能距離またはRDを変更したりしないでください。 ACTIVE状態中に受信したこのルートに関する更新情報は、CDにのみ反映されます。サクセサー、FD、およびRDに対する更新は、ルートがパッシブ状態に戻るまで延期されます。パッシブからアクティブへ、およびアクティブからパッシブへの状態遷移は、DUAL FSMによって制御され、セクション3.5で詳しく説明されています。
The Feasibility Condition is a criterion used to verify loop freedom of a particular path. The Feasibility Condition is a sufficient but not a necessary condition, meaning that every path meeting the Feasibility Condition is guaranteed to be loop free; however, not all loop-free paths meet the Feasibility Condition.
実現可能性条件は、特定のパスのループの自由を検証するために使用される基準です。実現可能性条件は十分ですが必要条件ではありません。つまり、実現可能性条件を満たすすべてのパスがループフリーであることが保証されます。ただし、ループのないすべてのパスが実現可能性条件を満たすとは限りません。
The Feasibility Condition is used as an integral part of DUAL operation: every path selection in DUAL is subject to the Feasibility Condition check. Based on the result of the Feasibility Condition check after a topology change is detected, the route may either remain PASSIVE (if, after the topology change, the neighbor providing the least cost path meets the Feasibility Condition) or it needs to enter the ACTIVE state (if the topology change resulted in none of the neighbors providing the least cost path to meet the Feasibility Condition).
実現可能性条件は、DUAL操作の不可欠な部分として使用されます。DUALでのすべてのパス選択は、実現可能性条件チェックの対象になります。トポロジの変更が検出された後のフィージビリティコンディションチェックの結果に基づいて、ルートはパッシブのままであるか（トポロジの変更後、最小コストパスを提供するネイバーがフィージビリティコンディションを満たす場合）、またはアクティブ状態に入る必要があります（トポロジーの変更の結果、実現可能性条件を満たすための最小コストのパスを提供するネイバーがない場合）。
The Feasibility Condition is a part of DUAL that allows the diffused computation to terminate as early as possible. Nodes that are not affected by the topology change are not required to perform a DUAL computation and may not be aware a topology change occurred. This can occur in two cases: First, if informed about a topology change, a router may keep a route in PASSIVE state if it is aware of other paths that are downstream towards the destination (routes meeting the Feasibility Condition). A route that meets the Feasibility Condition is determined to be loop free and downstream along the path between the router and the destination.
実現可能性条件はDUALの一部であり、拡散計算をできるだけ早く終了できます。トポロジ変更の影響を受けないノードは、DUAL計算を実行する必要がなく、トポロジ変更が発生したことに気付かない可能性があります。これは2つのケースで発生する可能性があります。最初に、トポロジ変更について通知された場合、宛先に向かってダウンストリームである他のパス（実現可能性条件を満たすルート）を認識していれば、ルーターはルートをパッシブ状態のままにすることがあります。実現可能性条件を満たすルートは、ルーターと宛先の間のパスに沿ってループフリーでダウンストリームであると判断されます。
Second, if informed about a topology change for which it does not currently have reachability information, a router is not required to enter into the ACTIVE state, nor is it required to participate in the DUAL process.
第2に、現在到達可能性情報を持たないトポロジ変更について通知された場合、ルータはACTIVE状態に入る必要がなく、DUALプロセスに参加する必要もありません。
In order to facilitate describing the Feasibility Condition, a few definitions are in order.
実現可能性条件の説明を容易にするために、いくつかの定義が適切です。
o A successor for a given route is the next hop used to forward data traffic for a destination. Typically, the successor is chosen based on the least-cost path to reach the destination.
o 特定のルートの後続ノードは、宛先のデータトラフィックを転送するために使用されるネクストホップです。通常、後続ノードは、宛先に到達するための最小コストパスに基づいて選択されます。
o A Feasible Successor is a neighbor that meets the Feasibility Condition. A Feasible Successor is regarded as a downstream neighbor towards the destination, but it may not be the least-cost path but could still be used for forwarding data packets in the event equal or unequal cost load sharing was active. A Feasible Successor can become a successor when the current successor becomes unreachable.
o フィジブルサクセサは、フィジビリティ条件を満たしているネイバーです。フィジブルサクセサは、宛先に向かうダウンストリームネイバーと見なされますが、最小コストのパスではない可能性がありますが、同等または不等コストのロードシェアリングがアクティブな場合に、データパケットの転送に使用できます。フィージブルサクセサは、現在の後継者が到達不能になったときにサクセサになることができます。
o The Feasibility Condition is met when a neighbor's advertised cost, (RD) to a destination is less than the FD for that destination, or in other words, the Feasibility Condition is met when the neighbor is closer to the destination than the router itself has ever been since the destination has entered the PASSIVE state for the last time.
o 宛先へのネイバーのアドバタイズされたコスト（RD）がその宛先のFDより小さい場合、つまり、ネイバーがルーター自体よりも宛先に近い場合に、フィージビリティー条件が満たされます。宛先が最後にパッシブ状態に入ってから。
o The FD is the lowest distance to the destination since the last time the route went from ACTIVE to PASSIVE state. It should be noted it is not necessarily the current best distance; rather, it is a historical record of the best distance known since the last diffusing computation for the destination has finished. Thus, the value of the FD can either be the same as the current best distance, or it can be lower.
o FDは、ルートが最後にアクティブ状態からパッシブ状態になったときから宛先までの最短距離です。これは必ずしも現在の最適距離ではないことに注意してください。むしろ、それは目的地の最後の拡散計算が終了してから既知の最良距離の履歴レコードです。したがって、FDの値は、現在の最適距離と同じにすることも、それよりも低くすることもできます。
A neighbor that advertises a route with a cost that does not meet the Feasibility Condition may be upstream and thus cannot be guaranteed to be the next hop for a loop-free path. Routes advertised by upstream neighbors are not recorded in the routing table but saved in the topology table.
実現可能性条件を満たさないコストでルートをアドバタイズするネイバーはアップストリームである可能性があるため、ループのないパスのネクストホップであるとは保証できません。アップストリームネイバーによってアドバタイズされたルートは、ルーティングテーブルには記録されませんが、トポロジテーブルに保存されます。
DUAL operates with three basic message types: QUERY, UPDATE, and REPLY.
DUALは、QUERY、UPDATE、REPLYという3つの基本的なメッセージタイプで動作します。
o UPDATE - sent to indicate a change in metric or an addition of a destination.
o UPDATE-メトリックの変更または宛先の追加を示すために送信されます。
o QUERY - sent when the Feasibility Condition fails, which can happen for reasons like a destination becoming unreachable or the metric increasing to a value greater than its current FD.
o QUERY-Feasibility Conditionが失敗したときに送信されます。これは、宛先が到達不能になった場合や、メトリックが現在のFDより大きい値に増加した場合などに発生します。
o REPLY - sent in response to a QUERY or SIA-QUERY
o REPLY-QUERYまたはSIA-QUERYへの応答として送信されます
In addition to these three basic types, two additional sub-types have been added to EIGRP:
これらの3つの基本タイプに加えて、2つのサブタイプがEIGRPに追加されました。
o SIA-QUERY - sent when a REPLY has not been received within one-half of the SIA interval (90 seconds as implemented by Cisco).
o SIA-QUERY-SIAインターバルの半分（シスコが実装した90秒）内にREPLYが受信されなかった場合に送信されます。
o SIA-REPLY - sent in response to an SIA-QUERY indicating the route is still in ACTIVE state. This response does not stratify the original QUERY; it is only used to indicate that the sending neighbor is still in the ACTIVE state for the given destination.
o SIA-REPLY-ルートがまだアクティブ状態であることを示すSIA-QUERYへの応答として送信されます。この応答は、元のクエリを層別化しません。これは、送信側ネイバーが指定された宛先に対してまだアクティブ状態であることを示すためにのみ使用されます。
When in the PASSIVE state, a received QUERY may be propagated if there is no Feasible Successor found. If a Feasible Successor is found, the QUERY is not propagated and a REPLY is sent for the destination with a metric equal to the current routing table metric. When a QUERY is received from a non-successor in ACTIVE state, a REPLY is sent and the QUERY is not propagated. The REPLY for the destination contains a metric equal to the current routing table metric.
パッシブ状態のときに、フィジブルサクセサが見つからない場合、受信したクエリが伝播されることがあります。 Feasible Successorが見つかった場合、QUERYは伝搬されず、現在のルーティングテーブルのメトリックと等しいメトリックを持つ宛先に対してREPLYが送信されます。 QUERYがACTIVE状態の非後続操作から受信されると、REPLYが送信され、QUERYは伝搬されません。宛先のREPLYには、現在のルーティングテーブルメトリックと等しいメトリックが含まれています。
The DUAL FSM embodies the decision process for all route computations. It tracks all routes advertised by all neighbors. The distance information, known as a metric, is used by DUAL to select efficient loop-free paths. DUAL selects routes to be inserted into a routing table based on Feasible Successors. A successor is a neighboring router used for packet forwarding that has a least-cost path to a destination that is guaranteed not to be part of a routing loop.
DUAL FSMは、すべてのルート計算の決定プロセスを具体化します。すべてのネイバーによってアドバタイズされるすべてのルートを追跡します。メトリックと呼ばれる距離情報は、DUALが効率的なループフリーパスを選択するために使用します。 DUALは、フィジブルサクセサに基づいてルーティングテーブルに挿入されるルートを選択します。サクセサは、ルーティングループの一部ではないことが保証されている宛先への最小コストパスを持つパケット転送に使用される隣接ルータです。
When there are no Feasible Successors but there are neighbors advertising the destination, a recalculation must occur to determine a new successor.
フィジブルサクセサはないが、宛先をアドバタイズするネイバーがいる場合、新しいサクセサを決定するために再計算を行う必要があります。
The amount of time it takes to calculate the route impacts the convergence time. Even though the recalculation is not processor intensive, it is advantageous to avoid recalculation if it is not necessary. When a topology change occurs, DUAL will test for Feasible Successors. If there are Feasible Successors, it will use any it finds in order to avoid any unnecessary recalculation.
ルートの計算にかかる時間は、収束時間に影響します。再計算はプロセッサに負荷をかけませんが、必要がない場合は再計算を回避することをお勧めします。トポロジの変更が発生すると、DUALはフィジブルサクセサをテストします。フィジブルサクセサがある場合、不必要な再計算を回避するために、検出されたサクセサが使用されます。
The FSM, which applies per destination in the topology table, operates independently for each destination. It is true that if a single link goes down, multiple routes may go into ACTIVE state. However, a separate SDAG is computed for each destination, so loop-free topologies can be maintained for each reachable destination.
トポロジテーブルの宛先ごとに適用されるFSMは、宛先ごとに独立して動作します。単一のリンクがダウンした場合、複数のルートがアクティブ状態になる可能性があることは事実です。ただし、宛先ごとに個別のSDAGが計算されるため、到達可能な宛先ごとにループのないトポロジを維持できます。
+------------+ +-----------+
| \ / |
| \ / |
| +=================================+ |
| | | |
|(1)| Passive |(2)|
+-->| |<--+
+=================================+
^ | ^ ^ ^ |
(14)| |(15)| |(13)| |
| (4)| |(16)| | (3)|
| | | | | +------------+
| | | | | \
+-------+ + + | +-------------+ \
/ / / | \ \
/ / / +----+ \ \
| | | | | |
| v | | | v
+==========+(11) +==========+ +==========+(12) +==========+
| Active |---->| Active |(5) | Active |---->| Active |
| | (9)| |---->| | (10)| |
| oij=0 |<----| oij=1 | | oij=2 |<----| oij=3 |
+--| | +--| | +--| | +--| |
| +==========+ | +==========+ | +==========+ | +==========+
| ^ |(5) | ^ | ^ ^ | ^
| | +-----|------|---------|----+ | | |
+------+ +------+ +---------+ +---------+
(6,7,8) (6,7,8) (6,7,8) (6,7,8)
Figure 1: DUAL Finite State Machine
図1：DUAL有限状態マシン
Legend:
伝説：
i Node that is computing route j Destination node or network k Any neighbor of node i oij QUERY origin flag 0 = metric increase during ACTIVE state 1 = node i originated 2 = QUERY from, or link increase to, successor during ACTIVE state 3 = QUERY originated from successor rijk REPLY status flag for each neighbor k for destination j 1 = awaiting REPLY 0 = received REPLY lik = the link connecting node i to neighbor k
iルートを計算しているノードj宛先ノードまたはネットワークkノードの任意のネイバーi oij QUERY発信元フラグ0 =アクティブ状態中にメトリックが増加1 =ノードiが発信した2 =アクティブ状態中に後続ノードからのクエリまたはリンク増加3 =クエリ宛先jの各ネイバーkの後続rijk REPLYステータスフラグから発生1 = REPLYを待機中0 =受信REPLY lik =ノードiをネイバーkに接続するリンク
The following describes in detail the state/event/action transitions of the DUAL FSM. For all steps, the topology table is updated with the new metric information from either QUERY, REPLY, or UPDATE received.
以下では、DUAL FSMの状態/イベント/アクションの遷移について詳しく説明します。すべてのステップで、トポロジテーブルは、受信したQUERY、REPLY、またはUPDATEからの新しいメトリック情報で更新されます。
(1) A QUERY is received from a neighbor that is not the current successor. The route is currently in PASSIVE state. As the successor is not affected by the QUERY, and a Feasible Successor exists, the route remains in PASSIVE state. Since a Feasible Successor exists, a REPLY MUST be sent back to the originator of the QUERY. Any metric received in the QUERY from that neighbor is recorded in the topology table and the Feasibility Check (FC) is run to check for any change to current successor.
（1）現在の後継者ではないネイバーからクエリを受信しました。ルートは現在パッシブ状態です。サクセサはクエリの影響を受けず、フィジブルサクセサが存在するため、ルートはパッシブ状態のままです。フィジブルサクセサが存在するため、クエリの発信者に返信を送信する必要があります。そのネイバーからQUERYで受信されたメトリックはトポロジテーブルに記録され、フィージビリティチェック（FC）が実行されて、現在の後継者への変更をチェックします。
(2) A directly connected interface changes state (connects, disconnects, or changes metric), or similarly an UPDATE or QUERY has been received with a metric change for an existing destination, the route will stay in the PASSIVE state if the current successor is not affected by the change, or it is no longer reachable and there is a Feasible Successor. In either case, an UPDATE is sent with the new metric information if it has changed.
（2）直接接続されたインターフェースが状態を変更（接続、切断、またはメトリックを変更）するか、または同様に、既存の宛先のメトリックが変更されたUPDATEまたはQUERYを受信した場合、現在の後続ノードがルートである場合、ルートはパッシブ状態のままになります変更の影響を受けていないか、到達不可能であり、フィジブルサクセサがあります。どちらの場合も、新しいメトリック情報が変更されている場合は、新しいメトリック情報とともにUPDATEが送信されます。
(3) A QUERY was received from a neighbor who is the current successor and no Feasible Successors exist. The route for the destination goes into ACTIVE state. A QUERY is sent to all neighbors on all interfaces that are not split horizon. Split horizon takes effect for a query or update from the successor it is using for the destination in the query. The QUERY origin flag is set to indicate the QUERY originated from a neighbor marked as successor for route. The REPLY status flag is set for all neighbors to indicate outstanding replies.
（3）現在の後継者であり、フィジブルサクセサが存在しないネイバーからクエリを受信しました。宛先のルートはアクティブ状態になります。クエリは、スプリットホライズンではないすべてのインターフェイス上のすべてのネイバーに送信されます。スプリットホライズンは、クエリまたはクエリ内の宛先に使用している後続からの更新に対して有効になります。 QUERY発信元フラグは、ルートの後続としてマークされたネイバーから発信されたQUERYを示すために設定されます。 REPLYステータスフラグは、すべてのネイバーに対して設定され、未解決の応答を示します。
(4) A directly connected link has gone down or its cost has increased, or an UPDATE has been received with a metric increase. The route to the destination goes to ACTIVE state if there are no Feasible Successors found. A QUERY is sent to all neighbors on all interfaces. The QUERY origin flag is to indicate that the router originated the QUERY. The REPLY status flag is set to 1 for all neighbors to indicate outstanding replies.
（4）直接接続されたリンクがダウンしたか、そのコストが増加したか、またはメトリックの増加とともにUPDATEが受信されました。フィージブルサクセサが見つからない場合、宛先へのルートはACTIVE状態になります。クエリは、すべてのインターフェイスのすべてのネイバーに送信されます。 QUERY発信元フラグは、ルーターがQUERYを発信したことを示します。すべてのネイバーのREPLYステータスフラグは、未解決の応答を示すために1に設定されます。
(5) While a route for a destination is in ACTIVE state, and a QUERY is received from the current successor, the route remains in ACTIVE state. The QUERY origin flag is set to indicate that there was another topology change while in ACTIVE state. This indication is used so new Feasible Successors are compared to the metric that made the route go to ACTIVE state with the current successor.
（5）宛先のルートがアクティブ状態で、現在の後継者からクエリを受信している間、ルートはアクティブ状態のままです。 QUERY発信元フラグは、ACTIVE状態の間に別のトポロジー変更があったことを示すために設定されます。この指標が使用されるので、新しいフィジブルサクセサーは、現在のサクセサーでルートをアクティブ状態にしたメトリックと比較されます。
(6) While a route for a destination is in ACTIVE state and a QUERY is received from a neighbor that is not the current successor, a REPLY should be sent to the neighbor. The metric received in the QUERY should be recorded.
（6）宛先のルートがACTIVE状態で、現在の後継者ではないネイバーからQUERYを受信している間は、REPLYをネイバーに送信する必要があります。 QUERYで受け取ったメトリックを記録する必要があります。
(7) If a link cost changes, or an UPDATE with a metric change is received in ACTIVE state from a non-successor, the router stays in ACTIVE state for the destination. The metric information in the UPDATE is recorded. When a route is in the ACTIVE state, neither a QUERY nor UPDATE are ever sent.
（7）リンクコストが変更された場合、またはメトリックが変更されたUPDATEが非後続ノードからアクティブ状態で受信された場合、ルータは宛先のアクティブ状態を維持します。 UPDATEのメトリック情報が記録されます。ルートがアクティブ状態の場合、QUERYもUPDATEも送信されません。
(8) If a REPLY for a destination, in ACTIVE state, is received from a neighbor or the link between a router and the neighbor fails, the router records that the neighbor replied to the QUERY. The REPLY status flag is set to 0 to indicate this. The route stays in ACTIVE state if there are more replies pending because the router has not heard from all neighbors.
（8）ACTIVE状態の宛先に対するREPLYがネイバーから受信された場合、またはルータとネイバー間のリンクに障害が発生した場合、ルータはネイバーがクエリに応答したことを記録します。 REPLYステータスフラグは0に設定され、これを示します。ルータはすべてのネイバーからの応答がないため、保留中の応答がまだある場合、ルートはアクティブ状態のままです。
(9) If a route for a destination is in ACTIVE state, and a link fails or a cost increase occurred between a router and its successor, the router treats this case like it has received a REPLY from its successor. When this occurs after the router originates a QUERY, it sets the QUERY origin flag to indicate that another topology change occurred in ACTIVE state.
（9）宛先のルートがACTIVE状態であり、リンクが失敗したか、ルーターとその後続ノードの間でコストの増加が発生した場合、ルーターはこのケースを後続ノードからREPLYを受信したものとして扱います。ルータがQUERYを発信した後にこれが発生すると、ルータはQUERY発信元フラグを設定して、ACTIVE状態で別のトポロジ変更が発生したことを示します。
(10) If a route for a destination is in ACTIVE state, and a link fails or a cost increase occurred between a router and its successor, the router treats this case like it has received a REPLY from its successor. When this occurs after a successor originated a QUERY, the router sets the QUERY origin flag to indicate that another topology change occurred in ACTIVE state.
（10）宛先へのルートがACTIVE状態であり、リンクが失敗するか、ルーターとその後続ノードの間でコストの増加が発生した場合、ルーターはこのケースを後続ノードからREPLYを受信したものとして扱います。サクセサがQUERYを発信した後にこれが発生すると、ルータはQUERY発信元フラグを設定して、別のトポロジ変更がアクティブ状態で発生したことを示します。
(11) If a route for a destination is in ACTIVE state, the cost of the link through which the successor increases, and the last REPLY was received from all neighbors, but there is no Feasible Successor, the route should stay in ACTIVE state. A QUERY is sent to all neighbors. The QUERY origin flag is set to 1.
（11）宛先のルートがACTIVE状態であり、サクセサが増加するリンクのコスト、およびすべてのネイバーから最後のREPLYが受信されたが、フィジブルサクセサがない場合、ルートはACTIVE状態のままである必要があります。 QUERYがすべてのネイバーに送信されます。 QUERYの起点フラグは1に設定されます。
(12) If a route for a destination is in ACTIVE state because of a QUERY received from the current successor, and the last REPLY was received from all neighbors, but there is no Feasible Successor, the route should stay in ACTIVE state. A QUERY is sent to all neighbors. The QUERY origin flag is set to 3.
（12）現在のサクセサーからQUERYを受信したために宛先のルートがアクティブ状態にあり、すべてのネイバーから最後のREPLYを受信したが、フィジブルサクセサーがない場合、ルートはアクティブ状態のままである必要があります。 QUERYがすべてのネイバーに送信されます。 QUERY発信元フラグは3に設定されます。
(13) Received replies from all neighbors. Since the QUERY origin flag indicates the successor originated the QUERY, it transitions to PASSIVE state and sends a REPLY to the old successor.
（13）すべてのネイバーから返信を受け取りました。 QUERY発信元フラグは、後続がQUERYを発信したことを示しているため、PASSIVE状態に移行し、REPLYを古い後続に送信します。
(14) Received replies from all neighbors. Since the QUERY origin flag indicates a topology change to the successor while in ACTIVE state, it need not send a REPLY to the old successor. When the Feasibility Condition is met, the route state transitions to PASSIVE.
（14）すべてのネイバーから応答を受け取りました。 QUERY発信元フラグは、ACTIVE状態の間にトポロジーがサクセサーに変更されたことを示すため、古いサクセサーにREPLYを送信する必要はありません。 Feasibility Conditionが満たされると、ルートステートはPASSIVEに移行します。
(15) Received replies from all neighbors. Since the QUERY origin flag indicates either the router itself originated the QUERY or FC was not satisfied with the replies received in ACTIVE state, FD is reset to infinite value and the minimum of all the reported metrics is chosen as FD and route transitions back to PASSIVE state. A REPLY is sent to the old-successor if oij flags indicate that there was a QUERY from successor.
（15）すべてのネイバーから返信を受け取りました。 QUERY発信元フラグは、ルーター自体がQUERYを発信したか、FCがアクティブ状態で受信した応答に満足しなかったことを示しているため、FDは無限値にリセットされ、報告されたすべてのメトリックの最小値がFDとして選択され、ルート遷移がパッシブに戻ります状態。後継者からのQUERYがあったことをoijフラグが示す場合、REPLYが旧後継者に送信されます。
(16) If a route for a destination is in ACTIVE state because of a QUERY received from the current successor or there was an increase in distance while in ACTIVE state, the last REPLY was received from all neighbors, and a Feasible Successor exists for the destination, the route can go into PASSIVE state and a REPLY is sent to the successor if oij indicates that QUERY was received from the successor.
（16）現在のサクセサーから受信したクエリのために宛先のルートがアクティブ状態にあるか、アクティブ状態の間に距離が増加した場合、最後のREPLYがすべてのネイバーから受信され、フィジブルサクセサーが存在します宛先、ルートはパッシブ状態になり、QUERYが後続ノードから受信されたことをoijが示す場合、REPLYが後続ノードに送信されます。
The following topology (Figure 2) will be used to provide an example of how DUAL is used to reroute after a link failure. Each node is labeled with its costs to destination N. The arrows indicate the successor (next hop) used to reach destination N. The least-cost path is selected.
次のトポロジー（図2）は、リンク障害後にDUALを使用して再ルーティングする方法の例を示すために使用されます。各ノードには、宛先Nへのコストがラベル付けされています。矢印は、宛先Nに到達するために使用される後続ノード（ネクストホップ）を示します。最小コストのパスが選択されます。
N
|
(1)A ---<--- B(2)
| |
^ |
| |
(2)D ---<--- C(3)
Figure 2: Stable Topology
図2：安定したトポロジ
In the case where the link between A and D fails (Figure 3);
AとDの間のリンクに障害が発生した場合（図3）。
N N
| |
A ---<--- B A ---<--- B
| | | |
X | ^ |
| | | |
D ---<--- C D ---<--- C
Q-> <-R
N
|
(1)A ---<--- B(2)
|
^
|
(4)D --->--- C(3)
Figure 3: Link between A and D Fails
図3：AとDの間のリンクが失敗する
Only observing the destination provided by node N, D enters the ACTIVE state and sends a QUERY to all its neighbors, in this case node C. C determines that it has a Feasible Successor and replies immediately with metric 3. C changes its old successor of D to its new single successor B and the route to N stays in PASSIVE state. D receives the REPLY and can transition out of ACTIVE state since it received replies from all its neighbors. D now has a viable path to N through C. D selects C as its successor to reach node N with a cost of 4.
ノードNから提供された宛先のみを監視し、Dはアクティブ状態に入り、クエリをそのすべての隣接ノード（この場合はノードC）に送信します。Cは、フィジブルサクセサがあると判断し、メトリック3ですぐに応答します。Cは新しい単一の後続ノードBへのDとNへのルートはパッシブ状態のままです。 DはREPLYを受信し、すべてのネイバーから応答を受信したため、ACTIVE状態から移行できます。これで、DはCを介してNへの実行可能なパスを持ちます。Dは、Cを後続ノードとして選択し、コスト4でノードNに到達します。
Notice that nodes A and B were not involved in the recalculation since they were not affected by the change.
ノードAとBは変更の影響を受けなかったため、再計算には関与していません。
Let's consider the situation in Figure 4, where Feasible Successors may not exist. If the link between node A and B fails, B goes into ACTIVE state for destination N since it has no Feasible Successors. Node B sends a QUERY to node C. C has no Feasible Successors, so it goes active for destination N; and since C has no neighbors, it replies to the QUERY, deletes the destination, and returns to the PASSIVE state for the unreachable route. As C removes the (now unreachable) destination from its table, C sends REPLY to its old successor. B receives this REPLY from C, and determines this is the last REPLY it is waiting on before determining what the new state of the route should be; on receiving this REPLY, B deletes the route to N from its routing table.
フィジブルサクセサが存在しない可能性がある図4の状況を考えてみましょう。ノードAとBの間のリンクに障害が発生した場合、フィジブルサクセサがないため、Bは宛先Nのアクティブ状態になります。ノードBはノードCにクエリを送信します。Cにはフィジブルサクセサがないため、宛先Nでアクティブになります。 Cにはネイバーがないため、CはQUERYに応答し、宛先を削除して、到達不能ルートのパッシブ状態に戻ります。 Cが（現在到達不能な）宛先をテーブルから削除すると、Cは古い後続ノードにREPLYを送信します。 BはCからこのREPLYを受信し、これがルートの新しい状態がどうなるかを決定する前にBが待機している最後のREPLYであると判断します。このREPLYを受信すると、BはルーティングテーブルからNへのルートを削除します。
Since B was the originator of the initial QUERY, it does not have to send a REPLY to its old successor (it would not be able to any ways, because the link to its old successor is down). Note that nodes A and D were not involved in the recalculation since their successors were not affected.
Bは最初のQUERYの発信者だったので、古いサクセサーにREPLYを送信する必要はありません（古いサクセサーへのリンクがダウンしているため、どの方法でも送信できません）。ノードAおよびDは、それらの後継ノードが影響を受けなかったため、再計算に関与しなかったことに注意してください。
N N
| |
(1)A ---<--- B(2) A ------- B Q
| | | | |^ ^
^ ^ ^ | v| |
| | | | | |
(2)D C(3) D C ACK R
Figure 4: No Feasible Successors When Link between A and B Fails
図4：AとBの間のリンクが失敗した場合、フィジブルサクセサなし
EIGRP uses five different packet types to handle session management and pass DUAL Message types:
EIGRPは5つの異なるパケットタイプを使用してセッション管理を処理し、DUALメッセージタイプを渡します。
HELLO Packets (includes ACK) QUERY Packets (includes SIA-Query) REPLY Packets (includes SIA-Reply) REQUEST Packets UPDATE Packets
HELLOパケット（ACKを含む）QUERYパケット（SIA-Queryを含む）REPLYパケット（SIA-Replyを含む）REQUESTパケットUPDATEパケット
EIGRP packets are directly encapsulated into a network-layer protocol, such as IPv4 or IPv6. While EIGRP is capable of using additional encapsulation (such as AppleTalk, IPX, etc.) no further encapsulation is specified in this document.
EIGRPパケットは、IPv4やIPv6などのネットワーク層プロトコルに直接カプセル化されます。 EIGRPは追加のカプセル化（AppleTalk、IPXなど）を使用できますが、このドキュメントではそれ以上のカプセル化は指定されていません。
Support for network-layer protocol fragmentation is not supported, and EIGRP will attempt to avoid a maximum size packets that exceed the interface MTU by sending multiple packets that are less than or equal to MTU-sized packets.
ネットワーク層プロトコルフラグメンテーションのサポートはサポートされていません。EIGRPは、MTUサイズのパケット以下の複数のパケットを送信することにより、インターフェイスMTUを超える最大サイズのパケットを回避しようとします。
Each packet transmitted will use either multicast or unicast network-layer destination addresses. When multicast addresses are used, a mapping for the data link multicast address (when available) must be provided. The source address will be set to the address of the sending interface, if applicable.
送信される各パケットは、マルチキャストまたはユニキャストのネットワーク層宛先アドレスを使用します。マルチキャストアドレスを使用する場合、データリンクマルチキャストアドレス（利用可能な場合）のマッピングを提供する必要があります。送信元アドレスは、該当する場合、送信インターフェイスのアドレスに設定されます。
The following network-layer multicast addresses and associated data link multicast addresses:
次のネットワーク層マルチキャストアドレスおよび関連するデータリンクマルチキャストアドレス：
224.0.0.10 for IPv4 "EIGRP Routers" [13]
FF02:0:0:0:0:0:0:A for IPv6 "EIGRP Routers" [14]
They will be used on multicast-capable media and will be media independent for unicast addresses. Network-layer addresses will be used and the mapping to media addresses will be achieved by the native protocol mechanisms.
これらはマルチキャスト対応メディアで使用され、ユニキャストアドレスに対してメディアに依存しません。ネットワーク層アドレスが使用され、メディアアドレスへのマッピングはネイティブプロトコルメカニズムによって実現されます。
UPDATE packets carry the DUAL UPDATE message type and are used to convey information about destinations and the reachability of those destinations. When a new neighbor is discovered, unicast UPDATE packets are used to transmit a full table to the new neighbor, so the neighbor can build up its topology table. In normal operation (other than neighbor startup such as a link cost changes), UPDATE packets are multicast. UPDATE packets are always transmitted reliably. Each TLV destination will be processed individually through the DUAL FSM.
UPDATEパケットはDUAL UPDATEメッセージタイプを伝送し、宛先とそれらの宛先の到達可能性に関する情報を伝えるために使用されます。新しいネイバーが検出されると、ユニキャストUPDATEパケットを使用してテーブル全体が新しいネイバーに送信されるため、ネイバーはトポロジテーブルを構築できます。通常の操作（リンクコストの変更などのネイバーの起動以外）では、UPDATEパケットはマルチキャストされます。 UPDATEパケットは常に確実に送信されます。各TLV宛先は、DUAL FSMを通じて個別に処理されます。
A QUERY packet carries the DUAL QUERY message type and is sent by a router to advertise that a route is in ACTIVE state and the originator is requesting alternate path information from its neighbors. An infinite metric is encoded by setting the delay part of the metric to its maximum value.
QUERYパケットはDUAL QUERYメッセージタイプを伝送し、ルートによってアクティブ状態にあり、発信者がそのネイバーに代替パス情報を要求していることをアドバタイズするためにルータから送信されます。無限メトリックは、メトリックの遅延部分を最大値に設定することによってエンコードされます。
If there is a topology change that causes multiple destinations to be marked ACTIVE, EIGRP will build one or more QUERY packets for all destinations present. The state of each route is recorded individually, so a responding QUERY or REPLY need not contain all the same destinations in a single packet. Since EIGRP uses a reliable transport mechanism, route QUERY packets are also guaranteed be reliably delivered.
複数の宛先がアクティブとマークされる原因となるトポロジ変更がある場合、EIGRPは存在するすべての宛先に対して1つ以上のQUERYパケットを構築します。各ルートの状態は個別に記録されるため、応答するQUERYまたはREPLYは、単一のパケットに同じ宛先をすべて含める必要はありません。 EIGRPは信頼性の高い転送メカニズムを使用しているため、ルートQUERYパケットも確実に配信されることが保証されています。
When a QUERY packet is received, each destination will trigger a DUAL event, and the state machine will run individually for each route. Once the entire original QUERY packet is processed, then a REPLY or SIA-REPLY will be sent with the latest information.
QUERYパケットが受信されると、各宛先はDUALイベントをトリガーし、ステートマシンはルートごとに個別に実行されます。元のQUERYパケット全体が処理されると、REPLYまたはSIA-REPLYが最新の情報とともに送信されます。
A REPLY packet carries the DUAL REPLY message type and will be sent in response to a QUERY or SIA-QUERY packet. The REPLY packet will include a TLV for each destination and the associated vector metric in its own topology table.
REPLYパケットはDUAL REPLYメッセージタイプを伝送し、QUERYまたはSIA-QUERYパケットへの応答として送信されます。 REPLYパケットには、宛先ごとのTLVと関連するベクトルメトリックが独自のトポロジテーブルに含まれます。
The REPLY packet is sent after the entire received QUERY packet is processed. When a REPLY packet is received, there is no reason to process the packet before an acknowledgment is sent. Therefore, an acknowledgment is sent immediately and then the packet is processed. The sending of the acknowledgment is accomplished either by sending an ACK packet or by piggybacking the acknowledgment onto another packet already being transmitted.
REPLYパケットは、受信したQUERYパケット全体が処理された後に送信されます。 REPLYパケットが受信されると、確認応答が送信される前にパケットを処理する理由はありません。したがって、確認がすぐに送信され、パケットが処理されます。確認応答の送信は、ACKパケットを送信するか、すでに送信されている別のパケットに確認応答をピギーバックすることによって行われます。
Each TLV destination will be processed individually through the DUAL FSM. When a QUERY is received for a route that doesn't exist in our topology table, a REPLY with an infinite metric is sent and an entry in the topology table is added with the metric in the QUERY if the metric is not an infinite value.
各TLV宛先は、DUAL FSMを通じて個別に処理されます。トポロジテーブルに存在しないルートのクエリが受信されると、無限のメトリックを持つREPLYが送信され、メトリックが無限の値でない場合、トポロジテーブルのエントリにクエリのメトリックが追加されます。
If a REPLY for a designation not in the Active state, or not in the topology table, EIGRP will acknowledge the packet and discard the REPLY.
アクティブ状態でない、またはトポロジテーブルにない指定に対するREPLYの場合、EIGRPはパケットを確認して、REPLYを破棄します。
When an EIGRP router transitions to ACTIVE state for a particular destination, a QUERY is sent to a neighbor and the ACTIVE timer is started to limit the amount of time a destination may remain in an ACTIVE state.
EIGRPルーターが特定の宛先のACTIVE状態に移行すると、QUERYがネイバーに送信され、ACTIVEタイマーが開始されて、宛先がACTIVE状態を維持できる時間を制限します。
A route is regarded as SIA when it does not receive a REPLY within a preset time. This time interval is broken into two equal periods following the QUERY, and up to three additional "busy" periods in which an SIA-QUERY packet is sent for the destination.
事前設定された時間内にREPLYを受信しない場合、ルートはSIAと見なされます。この時間間隔は、QUERYに続く2つの等しい期間と、SIA-QUERYパケットが宛先に送信される最大3つの追加の「ビジー」期間に分割されます。
This process is begun when a router sends a QUERY to its neighbor. After one-half the SIA time interval (default implementation is 90 seconds), the router will send an SIA-QUERY; this must be replied to with either a REPLY or SIA-REPLY. Any neighbor that fails to send either a REPLY or SIA-REPLY with-in one-half the SIA interval will result in the neighbor being deemed to be "stuck" in the active state.
このプロセスは、ルーターがそのネイバーにクエリを送信したときに開始されます。 SIA時間間隔の半分（デフォルトの実装は90秒）の後、ルーターはSIA-QUERYを送信します。これには、REPLYまたはSIA-REPLYのいずれかで応答する必要があります。 SIAインターバルの半分以内でREPLYまたはSIA-REPLYのいずれかを送信できなかったネイバーは、ネイバーがアクティブ状態で「スタック」していると見なされます。
Cisco also limits the number of SIA-REPLY messages allowed to three. Once the timeout occurs after the third SIA-REPLY with the neighbor remaining in an ACTIVE state (as noted in the SIA-Reply message), the neighbor being deemed to be "stuck" in the active state.
シスコでは、許可されるSIA-REPLYメッセージの数も3つに制限しています。 3回目のSIA-REPLYの後にタイムアウトが発生し、ネイバーがアクティブ状態のままになると（SIA-Replyメッセージに示されているように）、ネイバーはアクティブ状態で「スタック」していると見なされます。
If the SIA state is declared, DUAL may take one of two actions;
SIA状態が宣言されている場合、DUALは2つのアクションのいずれかを実行できます。
a) Delete the route from that neighbor, acting as if the neighbor had responded with an unreachable REPLY message from the neighbor.
a) そのネイバーからルートを削除し、そのネイバーがネイバーから到達不能なREPLYメッセージで応答したかのように動作します。
b) Delete all routes from that neighbor and reset the adjacency with that neighbor, acting as if the neighbor had responded with an unreachable message for all routes.
b) そのネイバーからすべてのルートを削除し、そのネイバーとの隣接関係をリセットします。これは、ネイバーがすべてのルートに対して到達不能メッセージで応答したかのように機能します。
Implementation note: Cisco currently implements option (b).
実装メモ：シスコは現在オプション（b）を実装しています。
When a QUERY is still outstanding and awaiting a REPLY from a neighbor, there is insufficient information to determine why a REPLY has not been received. A lost packet, congestion on the link, or a slow neighbor could cause a lack of REPLY from a downstream neighbor.
QUERYがまだ未解決であり、ネイバーからのREPLYを待機している場合、REPLYが受信されなかった理由を判別するのに十分な情報がありません。パケットの損失、リンクの輻輳、または遅いネイバーは、ダウンストリームネイバーからのREPLYの欠如を引き起こす可能性があります。
In order to try to ascertain if the neighboring device is still attempting to converge on the active route, EIGRP may send an SIA-QUERY packet to the active neighbor(s). This enables an EIGRP router to determine if there is a communication issue with the neighbor or if it is simply still attempting to converge with downstream routers.
ネイバーデバイスがまだアクティブルートで収束を試みているかどうかを確認するために、EIGRPはSIA-QUERYパケットをアクティブネイバーに送信する場合があります。これにより、EIGRPルーターは、ネイバーとの通信に問題があるのか、それとも単にダウンストリームルーターとの収束を試みているのかを判断できます。
By sending an SIA-QUERY, the originating router may extend the effective active time by resetting the ACTIVE timer that has been previously set, thus allowing convergence to continue so long as neighbor devices successfully communicate that convergence is still underway.
SIA-QUERYを送信することにより、発信元ルーターは、以前に設定されたACTIVEタイマーをリセットすることで有効アクティブ時間を延長し、近隣デバイスが収束がまだ進行中であることを正常に通信している限り、収束を継続できるようにします。
The SIA-QUERY packet SHOULD be sent on a per-destination basis at one-half of the ACTIVE timeout period. Up to three SIA-QUERY packets for a specific destination may be sent, each at a value of one-half the ACTIVE time, so long as each are successfully acknowledged and met with an SIA-REPLY.
SIA-QUERYパケットは、ACTIVEタイムアウト期間の半分で宛先ごとに送信する必要があります（SHOULD）。特定の宛先に対して最大3つのSIA-QUERYパケットを送信できます。それぞれのパケットが正常に確認され、SIA-REPLYに適合している限り、それぞれがACTIVE時間の半分の値になります。
Upon receipt of an SIA-QUERY packet, an EIGRP router should first send an ACK and then continue to process the SIA-QUERY information. The QUERY is sent on a per-destination basis at approximately one-half the active time.
SIA-QUERYパケットを受信すると、EIGRPルーターは最初にACKを送信し、次にSIA-QUERY情報の処理を続行します。クエリは、アクティブ時間の約半分で宛先ごとに送信されます。
If the EIGRP router is still active for the destination specified in the SIA-QUERY, the router should respond to the originator with the SIA-REPLY indicating that active processing for this destination is still underway by setting the ACTIVE flag in the packet upon response.
EIGRPルーターがSIA-QUERYで指定された宛先に対して引き続きアクティブである場合、ルーターはSIA-REPLYで発信元に応答し、応答時にパケットにACTIVEフラグを設定することにより、この宛先のアクティブな処理がまだ進行中であることを示します。
If the router receives an SIA-QUERY referencing a destination for which it has not received the original QUERY, the router should treat the packet as though it was a standard QUERY:
ルーターが、元のクエリを受信していない宛先を参照するSIA-QUERYを受信した場合、ルーターはパケットを標準のクエリであるかのように処理する必要があります。
1) Acknowledge the receipt of the packet
1）パケットの受信を確認します
2) Send a REPLY if a successor exists
2）後継者がいる場合に返信を送信する
3) If the SIA-QUERY is from the successor, transition to the ACTIVE state if and only if a Feasibility Condition check fails and send an SIA-REPLY with the ACTIVE bit set
3）SIA-QUERYがサクセサーからのものである場合、フィージビリティコンディションチェックが失敗した場合にのみ、ACTIVE状態に移行し、ACTIVEビットが設定されたSIA-REPLYを送信します。
An SIA-REPLY packet is the corresponding response upon receipt of an SIA-QUERY from an EIGRP neighbor. The SIA-REPLY packet will include a TLV for each destination and the associated vector metric in the topology table. The SIA-REPLY packet is sent after the entire received SIA-QUERY packet is processed.
SIA-REPLYパケットは、EIGRPネイバーからSIA-QUERYを受信したときの対応する応答です。 SIA-REPLYパケットには、各宛先のTLVと、トポロジテーブル内の関連するベクトルメトリックが含まれます。 SIA-REPLYパケットは、受信したSIA-QUERYパケット全体が処理された後に送信されます。
If the EIGRP router is still ACTIVE for a destination, the SIA-REPLY packet will be sent with the ACTIVE bit set. This confirms for the neighbor device that the SIA-QUERY packet has been processed by DUAL and that the router is still attempting to resolve a loop-free path (likely awaiting responses to its own QUERY to downstream neighbors).
EIGRPルーターが宛先に対してまだアクティブである場合、SIA-REPLYパケットは、ACTIVEビットが設定された状態で送信されます。これにより、SIA-QUERYパケットがDUALによって処理され、ルーターがループのないパスを解決しようとしていること（近隣のダウンストリームへの自身のQUERYへの応答を待機している可能性が高い）が近隣デバイスに確認されます。
The SIA-REPLY informs the recipient that convergence is complete or still ongoing; it is an explicit notification that the router is still actively engaged in the convergence process. This allows the device that sent the SIA-QUERY to determine whether it should continue to allow the routes that are not converged to be in the ACTIVE state or if it should reset the neighbor relationship and flush all routes through this neighbor.
SIA-REPLYは、コンバージェンスが完了しているか、まだ進行中であることを受信者に通知します。これは、ルータがまだコンバージェンスプロセスに積極的に関与していることを明示的に通知するものです。これにより、SIA-QUERYを送信したデバイスは、収束していないルートを引き続きアクティブ状態にすることを許可するか、ネイバー関係をリセットしてこのネイバーを介してすべてのルートをフラッシュするかを決定できます。
EIGRP has four basic components:
EIGRPには4つの基本コンポーネントがあります。
o Finite State Machine o Reliable Transport Protocol o Neighbor Discovery/Recovery o Route Management
o 有限状態機械o信頼できるトランスポートプロトコルo近隣探索/回復oルート管理
The detail of DUAL, the State Machine used by EIGRP, is covered in Section 3.5.
EIGRPで使用されるステートマシンであるDUALの詳細については、セクション3.5で説明します。
The reliable transport is responsible for guaranteed, ordered delivery of EIGRP packets to all neighbors. It supports intermixed transmission of multicast and unicast packets. Some EIGRP packets must be transmitted reliably and others need not. For efficiency, reliability is provided only when necessary.
信頼性の高いトランスポートは、すべてのネイバーへのEIGRPパケットの保証された順序付けられた配信を担当します。マルチキャストパケットとユニキャストパケットの混合送信をサポートします。 EIGRPパケットには、確実に送信する必要があるものと、そうでないものがあります。効率のために、信頼性は必要な場合にのみ提供されます。
For example, on a multi-access network that has multicast capabilities, such as Ethernet, it is not necessary to send HELLOs reliably to all neighbors individually. EIGRP sends a single multicast HELLO with an indication in the packet informing the receivers that the packet need not be acknowledged. Other types of packets, such as UPDATE packets, require acknowledgment and this is indicated in the packet. The reliable transport has a provision to send multicast packets quickly when there are unacknowledged packets pending. This helps ensure that convergence time remains low in the presence of varying speed links.
たとえば、イーサネットなどのマルチキャスト機能を持つマルチアクセスネットワークでは、HELLOを確実にすべてのネイバーに個別に送信する必要はありません。 EIGRPは、パケットに確認応答する必要がないことを受信者に通知するパケット内の指示とともに、単一のマルチキャストHELLOを送信します。 UPDATEパケットなどの他のタイプのパケットは確認応答を必要とし、これはパケットに示されます。信頼性の高いトランスポートには、保留中の未確認のパケットがある場合にマルチキャストパケットをすばやく送信する機能があります。これにより、さまざまな速度のリンクが存在する場合でも、コンバージェンス時間が低く抑えられます。
DUAL assumes there is lossless communication between devices and thus must depend on the transport protocol to guarantee that messages are transmitted reliably. EIGRP implements the reliable transport protocol to ensure ordered delivery and acknowledgment of any messages requiring reliable transmission. State variables such as a received sequence number, acknowledgment number, and transmission queues MUST be maintained on a per-neighbor basis.
DUALは、デバイス間にロスレス通信があることを想定しているため、メッセージが確実に送信されることを保証するためにトランスポートプロトコルに依存する必要があります。 EIGRPは信頼性の高いトランスポートプロトコルを実装し、信頼性の高い送信を必要とするメッセージの順序どおりの配信と確認応答を保証します。受信したシーケンス番号、確認応答番号、送信キューなどの状態変数は、ネイバーごとに維持する必要があります。
The following sequence number rules must be met for the EIGRP reliable transport protocol to work correctly:
EIGRPの信頼性の高いトランスポートプロトコルが正しく機能するためには、次のシーケンス番号ルールを満たす必要があります。
o A sender of a packet includes its global sequence number in the sequence number field of the fixed header. The sequence number wraps around to one when the maximum value is exceeded (sequence number zero is reserved for unreliable transmission). The sender includes the receivers sequence number in the acknowledgment number field of the fixed header.
o パケットの送信者は、固定ヘッダーのシーケンス番号フィールドにグローバルシーケンス番号を含めます。最大値を超えると、シーケンス番号は1に折り返されます（シーケンス番号0は、信頼性の低い伝送のために予約されています）。送信者は、固定ヘッダーの確認応答番号フィールドに受信者のシーケンス番号を含めます。
o Any packets that do not require acknowledgment must be sent with a sequence number of 0.
o 確認応答を必要としないパケットは、シーケンス番号0で送信する必要があります。
o Any packet that has an acknowledgment number of 0 indicates that sender is not expecting to explicitly acknowledge delivery. Otherwise, it is acknowledging a single packet.
o 確認応答番号が0のパケットは、送信者が配信を明示的に確認することを期待していないことを示します。それ以外の場合は、単一のパケットを確認しています。
o Packets that are network-layer multicast must contain acknowledgment number of 0.
o ネットワーク層マルチキャストであるパケットには、確認応答番号0が含まれている必要があります。
When a router transmits a packet, it increments its sequence number and marks the packet as requiring acknowledgment by all neighbors on the interface for which the packet is sent. When individual acknowledgments are unicast addressed by the receivers to the sender with the acknowledgment number equal to the packets sequence number, the sender SHALL clear the pending acknowledgment requirement for the packet from the respective neighbor.
ルーターがパケットを送信するとき、ルーターはシーケンス番号をインクリメントし、パケットが送信されるインターフェイス上のすべてのネイバーによる確認応答を必要とするパケットにマークを付けます。個々の確認応答が、受信者によってパケットのシーケンス番号と等しい確認番号で送信者にユニキャストアドレス指定されている場合、送信者は、それぞれのネイバーからのパケットに対する保留中の確認要求をクリアする必要があります（SHALL）。
If the required acknowledgment is not received for the packet, it MUST be retransmitted. Retransmissions will occur for a maximum of 5 seconds. This retransmission for each packet is tried 16 times, after which, if there is no ACK, the neighbor relationship is reset with the peer that didn't send the ACK.
パケットに対して必要な確認応答が受信されない場合は、再送信する必要があります。再送信は最大5秒間行われます。各パケットのこの再送信は16回試行されます。その後、ACKがない場合、ネイバー関係は、ACKを送信しなかったピアとリセットされます。
The protocol has no explicit windowing support. A receiver will acknowledge each packet individually and will drop packets that are received out of order.
このプロトコルは明示的なウィンドウ処理をサポートしていません。レシーバーは各パケットを個別に確認し、順不同で受信されたパケットをドロップします。
Implementation note: The exception to this occurs if a duplicate packet is received, and the acknowledgment for the original packet has been scheduled for transmission, but not yet sent. In this case, EIGRP will not send an acknowledgment for the duplicate packet, and the queued acknowledgment will acknowledge both the original and duplicate packet.
実装上の注意：これに対する例外は、重複したパケットが受信され、元のパケットの確認応答が送信用にスケジュールされているが、まだ送信されていない場合に発生します。この場合、EIGRPは重複パケットの確認応答を送信せず、キューに入れられた確認応答は、元のパケットと重複パケットの両方を確認応答します。
Duplicate packets are also discarded upon receipt. Acknowledgments are not accumulative. Therefore, an ACK with a non-zero sequence number acknowledges a single packet.
重複したパケットも受信時に破棄されます。謝辞は累積されません。したがって、0以外のシーケンス番号を持つACKは、単一のパケットを確認します。
There are situations when multicast and unicast packets are transmitted close together on multi-access broadcast-capable networks. The reliable transport mechanism MUST ensure that all multicasts are transmitted in order and not mix the order among unicast and multicast packets. The reliable transport provides a mechanism to deliver multicast packets in order to some receivers quickly, while some receivers have not yet received all unicast or previously sent multicast packets. The SEQUENCE_TYPE TLV in HELLO packets achieves this. This will be explained in more detail in this section.
マルチアクセスブロードキャスト対応ネットワークで、マルチキャストパケットとユニキャストパケットが近接して送信される場合があります。信頼性の高いトランスポートメカニズムは、すべてのマルチキャストが順番に送信され、ユニキャストパケットとマルチキャストパケット間で順序が混在しないようにする必要があります。信頼性の高いトランスポートは、一部のレシーバーがすべてのユニキャストまたは以前に送信されたマルチキャストパケットをまだ受信していない一方で、一部のレシーバーにマルチキャストパケットを迅速に配信するメカニズムを提供します。 HELLOパケットのSEQUENCE_TYPE TLVはこれを実現します。これについては、このセクションで詳しく説明します。
Figure 5 illustrates the reliable transport protocol on point-to-point links. There are two scenarios that may occur: an UPDATE-initiated packet exchange or a QUERY-initiated packet exchange.
図5は、ポイントツーポイントリンクでの信頼性の高いトランスポートプロトコルを示しています。発生する可能性のあるシナリオは2つあります。UPDATEで開始されたパケット交換またはQUERYで開始されたパケット交換です。
This example will assume no packet loss.
この例では、パケット損失がないと想定しています。
Router A Router B
ルーターAルーターB
An Example UPDATE Exchange
<----------------
UPDATE (multicast)
A receives packet SEQ=100, ACK=0
Add packet to A's retransmit list
---------------->
ACK (unicast)
SEQ=0, ACK=100 Receive ACK
Process UPDATE Delete packet from A's retransmit list
An Example QUERY Exchange
<----------------
QUERY (multicast)
A receives packet SEQ=101, ACK=0
Process QUERY Add packet to A's retransmit list
---------------->
REPLY (unicast)
SEQ=201, ACK=101 Process ACK
Delete packet from A's retransmit
list
Process REPLY packet
<----------------
ACK (unicast)
A receives packet SEQ=0, ACK=201
Figure 5: Reliable Transfer on Point-to-Point Links
図5：ポイントツーポイントリンクでの信頼性の高い転送
The UPDATE exchange sequence requires UPDATE packets sent to be delivered reliably. The UPDATE packet transmitted contains a sequence number that is acknowledged by a receipt of an ACK packet. If the UPDATE or the ACK packet is lost on the network, the UPDATE packet will be retransmitted.
UPDATE交換シーケンスでは、送信されるUPDATEパケットを確実に配信する必要があります。送信されたUPDATEパケットには、ACKパケットの受信によって確認応答されるシーケンス番号が含まれています。ネットワーク上でUPDATEまたはACKパケットが失われた場合、UPDATEパケットは再送信されます。
This example will assume there is heavy packet loss on a network.
この例では、ネットワーク上で大量のパケット損失があると想定しています。
Router A Router B
<----------------
UPDATE (multicast)
A receives packet SEQ=100, ACK=0
Add packet to A's retransmit list
---------------->
ACK (unicast)
SEQ=0, ACK=100 Receive ACK
Process UPDATE Delete packet from A's retransmit list
<--/LOST/--------------
UPDATE (multicast)
SEQ=101, ACK=0
Add packet to A's retransmit list
Retransmit Timer Expires
<----------------
Retransmit UPDATE (unicast)
SEQ=101, ACK=0
Keep packet on A's retransmit list
---------------->
ACK (unicast)
SEQ=0, ACK=101 Receive ACK
Process UPDATE Delete packet from A's retransmit list
Figure 6: Reliable Transfer on Lossy Point-to-Point Links
図6：損失のあるポイントツーポイントリンクでの信頼性の高い転送
Reliable delivery on multi-access LANs works in a similar fashion to point-to-point links. The initial packet is always multicast and subsequent retransmissions are unicast addressed. The acknowledgments sent are always unicast addressed. Figure 7 shows an example with four routers on an Ethernet.
マルチアクセスLANでの信頼性の高い配信は、ポイントツーポイントリンクと同様に機能します。最初のパケットは常にマルチキャストであり、その後の再送信はユニキャストでアドレス指定されます。送信される確認応答は常にユニキャストアドレス指定されます。図7は、イーサネット上に4つのルーターがある例を示しています。
Router B -----------+
|
Router C -----------+------------ Router A
|
Router D -----------+
An Example UPDATE Exchange
<----------------
A send UPDATE (multicast)
SEQ=100, ACK=0
Add packet to B's retransmit list
Add packet to C's retransmit list
Add packet to D's retransmit list
---------------->
B sends ACK (unicast)
SEQ=0, ACK=100 Receive ACK
Process UPDATE Delete packet from B's retransmit list
---------------->
C sends ACK (unicast)
SEQ=0, ACK=100 Receive ACK
Process UPDATE Delete packet from C's retransmit list
---------------->
D sends ACK (unicast)
SEQ=0, ACK=100 Receive ACK
Process UPDATE Delete packet from D's retransmit list
An Example QUERY Exchange
<----------------
A sends UPDATE (multicast)
SEQ=101, ACK=0
Add packet to B's retransmit list
Add packet to C's retransmit list
Add packet to D's retransmit list
---------------->
B sends REPLY (unicast) <----------------
SEQ=511, ACK=101 A sends ACK (unicast to B)
Process UPDATE SEQ=0, ACK=511
Delete packet from B's retransmit list
---------------->
C sends REPLY (unicast) <----------------
SEQ=200, ACK=101 A sends ACK (unicast to C)
Process UPDATE SEQ=0, ACK=200
Delete packet from C's retransmit list
---------------->
D sends REPLY (unicast) <----------------
SEQ=11, ACK=101 A sends ACK (unicast to D)
Process UPDATE SEQ=0, ACK=11
Delete packet from D's retransmit list
Figure 7: Reliable Transfer on Multi-Access Links
図7：マルチアクセスリンクでの信頼性の高い転送
And finally, a situation where numerous multicast and unicast packets are sent close together in a multi-access environment is illustrated in Figure 8.
最後に、マルチアクセス環境で多数のマルチキャストパケットとユニキャストパケットが接近して送信される状況を図8に示します。
Router B -----------+
|
Router C -----------+------------ Router A
|
Router D -----------+
<----------------
A sends UPDATE (multicast)
SEQ=100, ACK=0
---------------/LOST/-> Add packet to B's retransmit list
B sends ACK (unicast) Add packet to C's retransmit list
SEQ=0, ACK=100 Add packet to D's retransmit list
---------------->
C sends ACK (unicast)
SEQ=0, ACK=100 Delete packet from C's retransmit list
---------------->
D sends ACK (unicast)
SEQ=0, ACK=100 Delete packet from D's retransmit list
<----------------
A sends HELLO (multicast)
SEQ=0, ACK=0, SEQ_TLV listing B
B receives Hello, does not set CR-Mode C receives Hello, sets CR-Mode D receives Hello, sets CR-Mode
BがHelloを受信、CRモードを設定しないCがHelloを受信、CRモードを設定DがHelloを受信、CRモードを設定
<----------------
A sends UPDATE (multicast)
SEQ=101, ACK=0, CR-Flag=1
---------------/LOST/-> Add packet to B's retransmit list
B sends ACK (unicast) Add packet to C's retransmit list
SEQ=0, ACK=100 Add packet to D's retransmit list
B ignores UPDATE 101 because the CR-Flag is set and it is not in CR-Mode
Bは、CRフラグが設定されていてCRモードではないため、UPDATE 101を無視します。
---------------->
C sends ACK (unicast)
SEQ=0, ACK=101
---------------->
D sends ACK (unicast)
SEQ=0, ACK=101
<----------------
A resends UPDATE (unicast to B)
SEQ=100, ACK=0
B packet duplicate
--------------->
B sends ACK (unicast) A removes packet from retransmit list
SEQ=0, ACK=100
<----------------
A resends UPDATE (unicast to B)
SEQ=101, ACK=0
--------------->
B sends ACK (unicast) A removes packet from retransmit list
SEQ=0, ACK=101
Figure 8: Reliable Transfer on Multi-Access Links with Conditional Receive
図8：条件付き受信によるマルチアクセスリンクでの信頼性の高い転送
Initially, Router A sends a multicast addressed UPDATE packet on the LAN. B and C receive it and send acknowledgments. Router B receives the UPDATE, but the acknowledgment sent is lost on the network. Before the retransmission timer for Router B's packet expires, there is an event that causes a new multicast addressed UPDATE to be sent.
最初に、ルータAはマルチキャストアドレス指定されたUPDATEパケットをLANに送信します。 BとCはそれを受信し、確認応答を送信します。ルータBはUPDATEを受信しますが、送信された確認応答はネットワーク上で失われます。ルーターBのパケットの再送信タイマーが期限切れになる前に、新しいマルチキャストアドレス指定のUPDATEが送信される原因となるイベントがあります。
Router A detects that there is at least one neighbor on the interface with a full queue. Therefore, it MUST signal that neighbor not to receive the next packet or it would receive the retransmitted packet out of order. If all neighbors on the interface have a full queue, then EIGRP should reschedule the transmission of the UPDATE once the queues are no longer full.
ルータAは、キューがいっぱいのインターフェイス上に少なくとも1つのネイバーがあることを検出します。したがって、次のパケットを受信しないようにネイバーに通知する必要があります。そうしないと、再送信されたパケットが順不同で受信されます。インターフェイス上のすべてのネイバーにフルキューがある場合、EIGRPは、キューがフルでなくなると、UPDATEの送信を再スケジュールする必要があります。
Router A builds a HELLO packet with a SEQUENCE_TYPE TLV indicating all the neighbors that have full queues. In this case, the only neighbor address in the list is Router B. The HELLO packet is sent via multicast unreliably out the interface.
ルータAは、フルキューを持つすべてのネイバーを示すSEQUENCE_TYPE TLVを使用してHELLOパケットを作成します。この場合、リスト内の唯一のネイバーアドレスはルータBです。HELLOパケットは、マルチキャストを介してインターフェイスから確実に送信されません。
Routers C and D process the SEQUENCE_TYPE TLV by looking for their own addresses in the list. If not found, they put themselves in CR-Mode.
ルータCとDは、リストで自分のアドレスを探すことにより、SEQUENCE_TYPE TLVを処理します。見つからない場合は、CRモードに移行します。
Router B does not find its address in the SEQUENCE TLV peer list, so it enters CR-Mode. Packets received by Router B with the CR-Flag MUST be discarded and not acknowledged.
ルータBはSEQUENCE TLVピアリストでアドレスを見つけられないため、CRモードに入ります。ルータBがCR-Flagを使用して受信したパケットは、破棄して確認応答する必要があります。
Later, Router A will unicast transmit both packets 100 and 101 directly to Router B. Router B already has 100, so it discards and acknowledges it.
その後、ルーターAはパケット100と101の両方を直接ルーターBにユニキャスト送信します。ルーターBにはすでに100があるため、それを破棄して確認します。
Router B then accepts and acknowledges packet 101. Once an acknowledgment is received, Router A can remove both packets from Router B's transmission list.
次に、ルーターBはパケット101を受け入れて確認します。確認が受信されると、ルーターAはルーターBの送信リストから両方のパケットを削除できます。
By default, EIGRP limits itself to using no more than 50% of the bandwidth reported by an interface when determining packet-pacing intervals. If the bandwidth does not match the physical bandwidth (the network architect may have put in an artificially low or high bandwidth value to influence routing decisions), EIGRP may:
デフォルトでは、EIGRPは、パケットペーシング間隔を決定するときに、インターフェイスによって報告される帯域幅の50％以下を使用するように制限します。帯域幅が物理的な帯域幅と一致しない場合（ネットワークアーキテクトがルーティングの決定に影響を与えるために人為的に低いまたは高い帯域幅の値を入力した可能性があります）、EIGRPは次のことを行うことがあります。
1. Generate more traffic than the interface can handle, possibly causing drops, thereby impairing EIGRP performance.
1. インターフェイスが処理できるよりも多くのトラフィックを生成し、ドロップを引き起こす可能性があるため、EIGRPのパフォーマンスが低下します。
2. Generate a lot of EIGRP traffic that could result in little bandwidth remaining for user data. To control such transmissions, an interface-pacing timer is defined for the interfaces on which EIGRP is enabled. When a pacing timer expires, a packet is transmitted out on that interface.
2. 多くのEIGRPトラフィックを生成して、ユーザーデータ用の帯域幅をほとんど残さないようにします。このような送信を制御するために、EIGRPが有効になっているインターフェイスにインターフェイスペーシングタイマーが定義されています。ペーシングタイマーが期限切れになると、そのインターフェイスでパケットが送信されます。
Neighbor Discovery/Recovery is the process that routers use to dynamically learn of other routers on their directly attached networks. Routers MUST also discover when their neighbors become unreachable or inoperative. This process is achieved with low overhead by periodically sending small HELLO packets. As long as any packets are received from a neighbor, the router can determine that neighbor is alive and functioning. Only after a neighbor router is considered operational can the neighboring routers exchange routing information.
近隣探索/回復は、ルーターが直接接続されたネットワーク上の他のルーターを動的に学習するために使用するプロセスです。ルーターはまた、ネイバーが到達不能または動作不能になった場合も検出する必要があります。このプロセスは、小さなHELLOパケットを定期的に送信することにより、オーバーヘッドを抑えて実現されます。ネイバーからパケットを受信している限り、ルーターはネイバーが有効で機能していると判断できます。隣接ルータが動作可能であると見なされて初めて、隣接ルータはルーティング情報を交換できます。
Each router keeps state information about adjacent neighbors. When newly discovered neighbors are learned the address, interface, and Hold Time of the neighbor is noted. When a neighbor sends a HELLO, it advertises its Hold Time. The Hold Time is the amount of time a router treats a neighbor as reachable and operational. In addition to the HELLO packet, if any packet is received within the Hold Time period, then the Hold Time period will be reset. When the Hold Time expires, DUAL is informed of the topology change.
各ルータは、隣接するネイバーに関する状態情報を保持しています。新しく検出されたネイバーが学習されると、ネイバーのアドレス、インターフェイス、およびホールドタイムが記録されます。ネイバーがHELLOを送信すると、ホールドタイムをアドバタイズします。ホールドタイムは、ルータがネイバーを到達可能かつ動作可能として扱う時間です。 HELLOパケットに加えて、ホールドタイム期間内にパケットが受信されると、ホールドタイム期間がリセットされます。ホールドタイムが満了すると、トポロジの変更がDUALに通知されます。
When an EIGRP router is initialized, it will start sending HELLO packets out any interface on which EIGRP is enabled. HELLO packets, when used for neighbor discovery, are normally sent multicast addressed. The HELLO packet will include the configured EIGRP metric K-values. Two routers become neighbors only if the K-values are the same. This enforces that the metric usage is consistent throughout the Internet. Also included in the HELLO packet is a Hold Time value. This value indicates to all receivers the length of time in seconds that the neighbor is valid. The default Hold Time will be three times the HELLO interval. HELLO packets will be transmitted every 5 seconds (by default). There may be a configuration command that controls this value and therefore changes the Hold Time. HELLO packets are not transmitted reliably, so the sequence number should be set to 0.
EIGRPルーターが初期化されると、EIGRPが有効になっているすべてのインターフェースからHELLOパケットの送信が開始されます。 HELLOパケットは、近隣探索に使用される場合、通常はマルチキャストアドレスで送信されます。 HELLOパケットには、構成済みのEIGRPメトリックK値が含まれます。 K値が同じである場合にのみ、2つのルーターがネイバーになります。これにより、メトリックの使用がインターネット全体で一貫していることが強制されます。 HELLOパケットには、ホールドタイム値も含まれています。この値は、ネイバーが有効である時間の長さを秒単位ですべての受信者に示します。デフォルトのホールドタイムは、HELLOインターバルの3倍です。 HELLOパケットは5秒ごとに送信されます（デフォルト）。この値を制御し、それによって保持時間を変更する構成コマンドがある場合があります。 HELLOパケットは確実に送信されないため、シーケンス番号を0に設定する必要があります。
A router detects a new neighbor by receiving a HELLO packet from a neighbor not presently known. To ensure unicast and multicast packet delivery, the detecting neighbor will send a unicast UPDATE packet to the new neighbor with no routing information (the NULL UPDATE packet). The initial NULL UPDATE packet sent MUST have the INIT-Flag set and contain no topology information.
ルータは、現在知られていないネイバーからHELLOパケットを受信することにより、新しいネイバーを検出します。ユニキャストおよびマルチキャストパケットの配信を確実にするために、検出するネイバーは、ルーティング情報なしでユニキャストUPDATEパケットを新しいネイバーに送信します（NULL UPDATEパケット）。送信される最初のNULL UPDATEパケットにはINIT-Flagが設定されている必要があり、トポロジー情報は含まれていません。
Implementation note: The NULL UPDATE packet is used to ensure bidirectional UNICAST packet delivery as the NULL UPDATE and the ACK are both sent unicast. Additional UPDATE packets cannot be sent until the initial NULL UPDATE packet is acknowledged.
実装上の注意：NULL UPDATEとACKの両方がユニキャストで送信されるため、NULL UPDATEパケットは双方向UNICASTパケット配信を確実にするために使用されます。追加のUPDATEパケットは、最初のNULL UPDATEパケットが確認されるまで送信できません。
The INIT-Flag instructs the neighbor to advertise its routes, and it is also useful when a neighbor goes down and comes back up before the router detects it went down. In this case, the neighbor needs new routing information. The INIT-Flag informs the router to send it.
INIT-Flagはネイバーにルートをアドバタイズするように指示します。また、ルータがダウンしたことを検出する前にネイバーがダウンしてアップした場合にも役立ちます。この場合、ネイバーには新しいルーティング情報が必要です。 INIT-Flagは、ルーターにそれを送信するよう通知します。
Implementation note: When a router sends an UPDATE with the INIT-Flag set, and without the Restart (RS) flag set in the header, the receiving neighbor must also send an UPDATE with the INIT-Flag. Failure to do so will result in a Cisco device posting a "stuck in INIT state" error and subsequent discards.
実装上の注意：ルーターがINIT-Flagを設定してUPDATEを送信し、ヘッダーに再起動（RS）フラグを設定しない場合、受信ネイバーもINIT-Flagを使用してUPDATEを送信する必要があります。そうしないと、Ciscoデバイスが「stuck in INIT state」エラーをポストし、その後廃棄されます。
Router A Router B (just booted) (up and running)
ルーターAルーターB（起動直後）（稼働中）
(1)---------------->
HELLO (multicast) <---------------- (2)
SEQ=0, ACK=0 HELLO (multicast)
SEQ=0, ACK=0
<---------------- (3)
UPDATE (unicast)
SEQ=10, ACK=0, INIT
(4)----------------> UPDATE 11 is queued
UPDATE (unicast)
SEQ=100, ACK=10, INIT <---------------- (5)
UPDATE (unicast)
SEQ=11, ACK=100
All UPDATES sent
(6)--------------/lost/->
ACK (unicast)
SEQ=0, ACK=11
(5 seconds later)
<---------------- (7)
Duplicate received, UPDATE (unicast)
packet discarded SEQ=11, ACK=100
(8)--------------->
ACK (unicast)
SEQ=0, ACK=11
Figure 9: Initialization Sequence
図9：初期化シーケンス
(1) Router A sends a multicast HELLO and Router B discovers it.
（1）ルータAがマルチキャストHELLOを送信し、ルータBがそれを検出します。
(2) Router B sends an expedited HELLO and starts the process of sending its topology table to Router A. In addition, Router B sends the NULL UPDATE packet with the INIT-Flag. The second packet is queued, but it cannot be sent until the first is acknowledged.
（2）ルータBは優先HELLOを送信し、トポロジテーブルをルータAに送信するプロセスを開始します。さらに、ルータBはINIT-Flagを使用してNULL UPDATEパケットを送信します。 2番目のパケットはキューに入れられますが、最初のパケットが確認されるまで送信できません。
(3) Router A receives the first UPDATE packet and processes it as a DUAL event. If the UPDATE contains topology information, the packet will be processed and stored in a topology table. Router B sends its first and only UPDATE packet with an accompanied ACK.
（3）ルータAは最初のUPDATEパケットを受信し、それをDUALイベントとして処理します。 UPDATEにトポロジー情報が含まれている場合、パケットは処理され、トポロジーテーブルに格納されます。ルータBは、ACKを伴う最初の唯一のUPDATEパケットを送信します。
(4) Router B receives UPDATE packet 100 from Router A. Router B can dequeue packet 10 from A's transmission list since the UPDATE acknowledged 10. It can now send UPDATE packet 11 and with an acknowledgment of Router A's UPDATE.
（4）ルーターBはルーターAからUPDATEパケット100を受信します。ルーターBは、UPDATEが確認された10ので、パケット10をAの送信リストからデキューできます。これで、ルーターAのUPDATEの確認応答とともにUPDATEパケット11を送信できます。
(5) Router A receives the last UPDATE packet from Router B and acknowledges it. The acknowledgment gets lost.
（5）ルーターAはルーターBから最後のUPDATEパケットを受信し、それを確認します。確認は失われます。
(6) Router B later retransmits the UPDATE packet to Router A.
（6）ルーターBは後でUPDATEパケットをルーターAに再送信します。
(7) Router A detects the duplicate and simply acknowledges the packet. Router B dequeues packet 11 from A's transmission list, and both routers are up and synchronized.
（7）ルーターAが重複を検出し、パケットを確認します。ルータBはパケット11をAの送信リストからデキューし、両方のルータが起動して同期されます。
To prevent packets from being sent to a neighbor prior to verifying multicast and unicast packet delivery is reliable, a three-way handshake is utilized.
マルチキャストおよびユニキャストパケットの配信が信頼できることを確認する前に、パケットがネイバーに送信されないようにするために、3ウェイハンドシェイクが利用されます。
During normal adjacency formation, multicast HELLOs cause the EIGRP process to place new neighbors into the neighbor table. Unicast packets are then used to exchange known routing information and complete the neighbor relationship (Section 5.2).
通常の隣接関係の形成中、マルチキャストHELLOにより、EIGRPプロセスは新しいネイバーをネイバーテーブルに配置します。ユニキャストパケットは、既知のルーティング情報を交換し、ネイバー関係を完了するために使用されます（セクション5.2）。
To prevent EIGRP from sending sequenced packets to neighbors that fail to have bidirectional unicast/multicast, or one neighbor restarts while building the relationship, EIGRP MUST place the newly discovered neighbor in a "pending" state as follows:
EIGRPがシーケンス化されたパケットを双方向ユニキャスト/マルチキャストに失敗したネイバーに送信しないようにするか、1つのネイバーが関係の構築中に再起動するのを防ぐために、EIGRPは新しく検出されたネイバーを次のように「保留」状態にする必要があります。
when Router A receives the first multicast HELLO from Router B, it places Router B in the pending state and transmits a unicast UPDATE containing no topology information and SHALL set the initialization bit. While Router B is in this state, A will send it neither a QUERY nor an UPDATE. When Router A receives the unicast acknowledgment from Router B, it will change the state from "pending" to "up".
ルーターAがルーターBから最初のマルチキャストHELLOを受信すると、ルーターBを保留状態にして、トポロジ情報を含まないユニキャストUPDATEを送信し、初期化ビットを設定する必要があります（SHALL）。ルーターBがこの状態にある間、AはQUERYもUPDATEも送信しません。ルーターAがルーターBからユニキャスト確認応答を受信すると、状態を「保留」から「アップ」に変更します。
As described above, during the initial formation of the neighbor relationship, EIGRP uses a form of three-way handshake to verify both unicast and multicast connectivity are working successfully. During this period of neighbor creation, the new neighbor is considered to be in the pending state, and it is not eligible to be included in the convergence process.
上記のように、ネイバー関係の初期形成中に、EIGRPは3ウェイハンドシェイクの形式を使用して、ユニキャスト接続とマルチキャスト接続の両方が正常に機能していることを確認します。ネイバー作成のこの期間中、新しいネイバーは保留状態であると見なされ、コンバージェンスプロセスに含める資格がありません。
Because of this, any QUERY received by an EIGRP router would not cause a QUERY to be sent to the new (and pending) neighbor. It would perform the DUAL process without the new peer in the conversation. To do this, when a router in the process of establishing a new neighbor receives a QUERY from a fully established neighbor, it performs the normal DUAL Feasible Successor check to determine whether it needs to REPLY with a valid path or whether it needs to enter the ACTIVE process on the prefix.
このため、EIGRPルーターが受信したQUERYは、QUERYを新しい（および保留中の）ネイバーに送信しません。それは会話の新しいピアなしでDUALプロセスを実行します。これを行うには、新しいネイバーを確立している途中のルーターが完全に確立されたネイバーからQUERYを受信すると、通常のDUAL Feasible Successorチェックを実行して、有効なパスで応答する必要があるかどうか、またはプレフィックスのACTIVEプロセス。
If it determines that it must go active, each fully established neighbor that participates in the convergence process will be sent a QUERY packet, and REPLY packets are expected from each. Any pending neighbor will not be expected to REPLY and will not be sent a QUERY directly. If it resides on an interface containing a mix of fully established neighbors and pending neighbors, it might receive the QUERY, but it will not be expected to REPLY to it.
アクティブにする必要があると判断した場合、コンバージェンスプロセスに参加する完全に確立された各ネイバーにはQUERYパケットが送信され、それぞれからREPLYパケットが予期されます。保留中のネイバーは返信することは期待されず、直接クエリが送信されることはありません。完全に確立されたネイバーと保留中のネイバーが混在するインターフェイスに存在する場合、QUERYを受信する可能性がありますが、それに応答することは期待されません。
The topology table is populated by the Protocol-Dependent Modules (PDMs) (IPv4/IPv6), and it is acted upon by the DUAL finite state machine. Associated with each entry are the destination address, a list of neighbors that have advertised this destination, and the metric associated with the destination. The metric is referred to as the "CD".
トポロジテーブルには、プロトコル依存モジュール（PDM）（IPv4 / IPv6）が入力され、DUAL有限状態マシンによって実行されます。各エントリには、宛先アドレス、この宛先をアドバタイズしたネイバーのリスト、および宛先に関連付けられているメトリックが関連付けられています。メトリックは「CD」と呼ばれます。
The CD is the best-advertised RD from all neighbors, plus the link cost between the receiving router and the neighbor.
CDは、すべてのネイバーから最もよくアドバタイズされたRDに、受信ルーターとネイバー間のリンクコストを加えたものです。
The "RD" is the CD as advertised by the Feasible Successor for the destination. In other words, the Computed Distance, when sent by a neighbor, is referred to as the "Reported Distance" and is the metric that the neighboring router uses to reach the destination (its CD as described above).
「RD」は、宛先のFeasible SuccessorによってアドバタイズされたCDです。言い換えると、計算された距離は、ネイバーから送信された場合、「報告された距離」と呼ばれ、ネイバールータが宛先（上記のCD）に到達するために使用するメトリックです。
If the router is advertising a destination route, it MUST be using the route to forward packets; this is an important rule that distance vector protocols MUST follow.
ルーターが宛先ルートをアドバタイズしている場合は、そのルートを使用してパケットを転送する必要があります。これは、距離ベクトルプロトコルが従わなければならない重要な規則です。
Within the topology table, EIGRP has the notion of internal and external routes. Internal routes MUST be preferred over external routes, independent of the metric. In practical terms, if an internal route is received, the diffusing computation will be run considering only the internal routes. Only when no internal routes for a given destination exist will EIGRP choose the successor from the available external routes.
トポロジテーブル内で、EIGRPには内部ルートと外部ルートの概念があります。メトリックに関係なく、内部ルートは外部ルートよりも優先される必要があります。実際には、内部ルートが受信されると、内部ルートのみを考慮して拡散計算が実行されます。 EIGRPは、特定の宛先の内部ルートが存在しない場合にのみ、使用可能な外部ルートから後続ノードを選択します。
Internal routes are destinations that have been originated within the same EIGRP AS. Therefore, a directly attached network that is configured to run EIGRP is considered an internal route and is propagated with this information throughout the network topology.
内部ルートは、同じEIGRP AS内で発信された宛先です。したがって、EIGRPを実行するように構成されている直接接続されたネットワークは内部ルートと見なされ、この情報と共にネットワークトポロジ全体に伝達されます。
Internal routes are tagged with the following information:
内部ルートには、次の情報がタグ付けされています。
o Router ID of the EIGRP router that originated the route. o Configurable administrator tag.
o ルートを発信したEIGRPルーターのルーターID。 o設定可能な管理者タグ。
External routes are destinations that have been learned from another source, such as a different routing protocol or static route. These routes are marked individually with the identity of their origination. External routes are tagged with the following information:
外部ルートは、別のルーティングプロトコルや静的ルートなど、別のソースから学習した宛先です。これらのルートは、発信元のIDで個別にマークされます。外部ルートには次の情報がタグ付けされています。
o Router ID of the EIGRP router that redistributed the route. o AS number where the destination resides. o Configurable administrator tag. o Protocol ID of the external protocol. o Metric from the external protocol. o Bit flags for default routing.
o ルートを再配布したEIGRPルーターのルーターID。 o宛先が存在するAS番号。 o設定可能な管理者タグ。 o外部プロトコルのプロトコルID。 o外部プロトコルからのメトリック。 oデフォルトルーティングのビットフラグ。
As an example, suppose there is an AS with three border routers: BR1, BR2, and BR3. A border router is one that runs more than one routing protocol. The AS uses EIGRP as the routing protocol. Two of the border routers, BR1 and BR2, also use Open Shortest Path First (OSPF) [10] and the other, BR3, also uses the Routing Information Protocol (RIP).
例として、BR1、BR2、およびBR3の3つの境界ルーターを持つASがあるとします。ボーダールーターは、複数のルーティングプロトコルを実行するルーターです。 ASはルーティングプロトコルとしてEIGRPを使用します。境界ルーターの2つ、BR1とBR2もOpen Shortest Path First（OSPF）[10]を使用し、もう1つ、BR3もRouting Information Protocol（RIP）を使用します。
Routes learned by one of the OSPF border routers, BR1, can be conditionally redistributed into EIGRP. This means that EIGRP running in BR1 advertises the OSPF routes within its own AS. When it does so, it advertises the route and tags it as an OSPF-learned route with a metric equal to the routing table metric of the OSPF route. The router-id is set to BR1. The EIGRP route propagates to the other border routers.
OSPF境界ルーターの1つであるBR1によって学習されたルートは、条件付きでEIGRPに再配布できます。つまり、BR1で実行されているEIGRPは、自身のAS内でOSPFルートをアドバタイズします。その場合、ルートをアドバタイズし、OSPFルートのルーティングテーブルメトリックと等しいメトリックを持つOSPF学習ルートとしてタグ付けします。 router-idはBR1に設定されています。 EIGRPルートは他の境界ルータに伝播します。
Let's say that BR3, the RIP border router, also advertises the same destinations as BR1. Therefore, BR3, redistributes the RIP routes into the EIGRP AS. BR2, then, has enough information to determine the AS entry point for the route, the original routing protocol used, and the metric.
RIP境界ルーターであるBR3もBR1と同じ宛先をアドバタイズするとします。したがって、BR3はRIPルートをEIGRP ASに再配布します。次に、BR2には、ルートのASエントリポイント、使用された元のルーティングプロトコル、およびメトリックを決定するための十分な情報があります。
Further, the network administrator could assign tag values to specific destinations when redistributing the route. BR2 can utilize any of this information to use the route or re-advertise it back out into OSPF.
さらに、ネットワーク管理者は、ルートを再配布するときに特定の宛先にタグ値を割り当てることができます。 BR2は、この情報を利用してルートを使用したり、OSPFに再アドバタイズしたりできます。
Using EIGRP route tagging can give a network administrator flexible policy controls and help customize routing. Route tagging is particularly useful in transit ASes where EIGRP would typically interact with an inter-domain routing protocol that implements global policies.
EIGRPルートタギングを使用すると、ネットワーク管理者に柔軟なポリシー制御を提供し、ルーティングをカスタマイズできます。ルートタギングは、EIGRPがグローバルポリシーを実装するドメイン間ルーティングプロトコルと通常相互作用するトランジットASで特に役立ちます。
In some circumstances, EIGRP will suppress or poison QUERY and UPDATE information to prevent routing loops as changes propagate though the network.
状況によっては、EIGRPはQUERYおよびUPDATE情報を抑制または汚染して、変更がネットワークに伝播するときにルーティングループを防止します。
Within Cisco, the split horizon rule suggests: "Never advertise a route out of the interface through which it was learned". EIGRP implements this to mean, "if you have a successor route to a destination, never advertise the route out the interface on which it was learned".
シスコ内では、スプリットホライズンルールにより、「それが学習されたインターフェイスからルートをアドバタイズしないでください」と提案されています。 EIGRPはこれを実装して、「宛先への後続ルートがある場合は、それが学習されたインターフェイスからルートをアドバタイズしないでください」と意味しています。
The poison reverse rule states: "A route learned through an interface will be advertised as unreachable through that same interface". As with the case of split horizon, EIGRP applies this rule only to interfaces it is using for reaching the destination. Routes learned though interfaces that EIGRP is NOT using to reach the destination may have the route advertised out those interfaces.
ポイズンリバースルールには、「インターフェイスを介して学習されたルートは、同じインターフェイスを介して到達不能としてアドバタイズされます」と記載されています。スプリットホライズンの場合と同様に、EIGRPは宛先に到達するために使用しているインターフェイスにのみこのルールを適用します。 EIGRPが宛先に到達するために使用していないインターフェースを通じて学習されたルートは、それらのインターフェースからアドバタイズされたルートを持っている可能性があります。
In EIGRP, split horizon suppresses a QUERY, where as poison reverse advertises a destination as unreachable. This can occur for a destination under any of the following conditions:
EIGRPでは、スプリットホライズンはQUERYを抑制し、ポイズンリバースとして宛先を到達不能としてアドバタイズします。これは、次のいずれかの条件の宛先で発生する可能性があります。
o two routers are in startup or restart mode o advertising a topology table change o sending a query
o 2台のルーターが起動または再起動モードにあるoトポロジテーブルの変更を通知するoクエリを送信する
When two routers first become neighbors, they exchange topology tables during startup mode. For each destination a router receives during startup mode, it advertises the same destination back to its new neighbor with a maximum metric (Poison Route).
2台のルータが最初にネイバーになるとき、それらはスタートアップモード中にトポロジテーブルを交換します。起動モード中にルーターが受信する宛先ごとに、同じ宛先を最大メトリック（毒物ルート）で新しいネイバーにアドバタイズします。
If a router uses a neighbor as the successor for a given destination, it will send an UPDATE for the destination with a metric of infinity.
ルーターが特定の宛先の後続ノードとしてネイバーを使用する場合、無限のメトリックを使用して宛先のUPDATEを送信します。
In most cases, EIGRP follows normal split-horizon rules. When a metric change is received from the successor via QUERY or UPDATE that causes the route to go ACTIVE, the router will send a QUERY to neighbors on all interfaces except the interface toward the successor.
ほとんどの場合、EIGRPは通常のスプリットホライズンルールに従います。ルートがアクティブになる原因となるメトリック変更がQUERYまたはUPDATEを介して後続ノードから受信されると、ルータは後続ノードに向かうインターフェイスを除くすべてのインターフェイスのネイバーにクエリを送信します。
In other words, the router does not send the QUERY out of the inbound interface through which the information causing the route to go ACTIVE was received.
つまり、ルーターは、ルートをアクティブにする情報を受信した受信インターフェイスからクエリを送信しません。
An exception to this can occur if a router receives a QUERY from its successor while already reacting to an event that did not cause it to go ACTIVE, for example, a metric change from the successor that did not cause an ACTIVE transition, but was followed by the UPDATE/QUERY that does result the router to transition to ACTIVE.
これに対する例外は、ルータが後続ノードからQUERYを受け取ったときに、それをアクティブにさせなかったイベントにすでに反応している場合に発生する可能性があります。たとえば、アクティブ遷移を引き起こさなかったが追跡された後続ノードからのメトリック変更UPDATE / QUERYにより、ルータはACTIVEに移行します。
EIGRP allows for modification of the default composite metric calculation (see Section 5.6) through the use of coefficients (K-values). This adjustment allows for per-deployment tuning of network behavior. Setting K-values up to 254 scales the impact of the scalar metric on the final composite metric.
EIGRPでは、係数（K値）を使用して、デフォルトの複合メトリック計算（セクション5.6を参照）を変更できます。この調整により、ネットワーク動作のデプロイメントごとの調整が可能になります。 K値を最大254に設定すると、最終的な複合メトリックに対するスカラーメトリックの影響がスケーリングされます。
EIGRP default coefficients have been carefully selected to provide optimal performance in most networks. The default K-values are as follows:
EIGRPのデフォルト係数は、ほとんどのネットワークで最適なパフォーマンスを提供するように慎重に選択されています。デフォルトのK値は次のとおりです。
K1 == K3 == 1
K2 == K4 == K5 == 0
K6 == 0
If K5 is equal to 0, then reliability quotient is defined to be 1.
K5が0に等しい場合、信頼性指数は1として定義されます。
K1 is used to allow path selection to be based on the bandwidth available along the path. EIGRP can use one of two variations of Throughput-based path selection.
K1は、パスに沿って利用可能な帯域幅に基づいてパスを選択できるようにするために使用されます。 EIGRPは、スループットベースのパス選択の2つのバリエーションのいずれかを使用できます。
o Maximum Theoretical Bandwidth: paths chosen based on the highest reported bandwidth
o 最大理論帯域幅：報告された最大帯域幅に基づいて選択されたパス
o Network Throughput: paths chosen based on the highest "available" bandwidth adjusted by congestion-based effects (interface reported load)
o ネットワークスループット：輻輳ベースの効果によって調整された最高の「利用可能な」帯域幅に基づいて選択されたパス（インターフェースで報告された負荷）
By default, EIGRP computes the Throughput using the maximum theoretical Throughput expressed in picoseconds per kilobyte of data sent. This inversion results in a larger number (more time) ultimately generating a worse metric.
デフォルトでは、EIGRPは、送信されるデータのキロバイトあたりのピコ秒で表される理論上の最大スループットを使用してスループットを計算します。この反転の結果、より大きな数値（より多くの時間）が生成され、最終的にはより悪いメトリックが生成されます。
If K2 is used, the effect of congestion as a measure of load reported by the interface will be used to simulate the "available Throughput" by adjusting the maximum Throughput.
K2が使用されている場合、インターフェースによって報告された負荷の尺度としての輻輳の影響は、最大スループットを調整することによって「使用可能なスループット」をシミュレートするために使用されます。
K3 is used to allow delay or latency-based path selection. Latency and delay are similar terms that refer to the amount of time it takes a bit to be transmitted to an adjacent neighbor. EIGRP uses one-way-based values either provided by the interface or computed as a factor of the link s bandwidth.
K3は、遅延または遅延ベースのパス選択を可能にするために使用されます。遅延と遅延は同様の用語であり、隣接するネイバーにビットが送信されるのにかかる時間を指します。 EIGRPは、インターフェイスによって提供されるか、リンクの帯域幅の係数として計算される一方向ベースの値を使用します。
K4 and K5 are used to allow for path selection based on link quality and packet loss. Packet loss caused by network problems results in highly noticeable performance issues or Jitter with streaming technologies, voice over IP, online gaming and videoconferencing, and will affect all other network applications to one degree or another.
K4とK5は、リンク品質とパケット損失に基づいてパスを選択できるようにするために使用されます。ネットワークの問題によって引き起こされるパケット損失は、ストリーミング技術、Voice over IP、オンラインゲーム、およびビデオ会議でのパフォーマンスの問題またはジッターを非常に顕著にし、他のすべてのネットワークアプリケーションにある程度影響します。
Critical services should pass with less than 1% packet loss. Lower priority packet types might pass with less than 5% and then 10% for the lowest of priority of services. The final metric can be weighted based on the reported link quality.
重要なサービスは、1％未満のパケット損失で通過する必要があります。優先度の低いパケットタイプは5％未満で通過し、サービスの優先度が最も低い場合は10％で通過する可能性があります。最終的なメトリックは、報告されたリンク品質に基づいて重み付けできます。
The handling of K5 is conditional. If K5 is equal to 0, then reliability quotient is defined to be 1.
K5の処理は条件付きです。 K5が0に等しい場合、信頼性指数は1として定義されます。
K6 has been introduced with Wide Metric support and is used to allow for Extended Attributes, which can be used to reflect in a higher aggregate metric than those having lower energy usage. Currently there are two Extended Attributes, Jitter and energy, defined in the scope of this document.
K6はワイドメトリックサポートで導入され、拡張属性を可能にするために使用されます。拡張属性を使用すると、エネルギー使用量が少ないものよりも高い集約メトリックに反映できます。現在、このドキュメントの範囲で定義されている2つの拡張属性、ジッターとエネルギーがあります。
Use of Jitter-based Path Selection results in a path calculation with the lowest reported Jitter. Jitter is reported as the interval between the longest and shortest packet delivery and is expressed in microseconds. Higher values result in a higher aggregate metric when compared to those having lower Jitter calculations.
ジッタベースのパス選択を使用すると、レポートされたジッタが最も低いパス計算になります。ジッタは、最長と最短のパケット配信の間隔として報告され、マイクロ秒で表されます。値が高いほど、ジッターの計算が低い値と比較して、総計メトリックが高くなります。
Jitter is measured in microseconds and is accumulated along the path, with each hop using an averaged 3-second period to smooth out the metric change rate.
ジッタはマイクロ秒単位で測定され、パスに沿って累積されます。各ホップは、平均3秒の期間を使用してメトリックの変化率を平滑化します。
Presently, EIGRP does not have the ability to measure Jitter, and, as such, the default value will be zero (0). Performance-based solutions such as PfR could be used to populate this field.
現在、EIGRPにはジッターを測定する機能がないため、デフォルト値はゼロ（0）になります。 PfRなどのパフォーマンスベースのソリューションを使用して、このフィールドにデータを入力できます。
Use of Energy-based Path Selection results in paths with the lowest energy usage being selected in a loop-free and deterministic manner. The amount of energy used is accumulative and has results in a higher aggregate metric than those having lower energy.
エネルギーベースのパス選択を使用すると、最小のエネルギー使用量のパスがループフリーで確定的な方法で選択されます。使用されるエネルギーの量は累積的であり、より低いエネルギーを有するものよりも高い総計メトリックをもたらす。
Presently, EIGRP does not report energy usage, and as such the default value will be zero (0).
現在、EIGRPはエネルギー使用量を報告しないため、デフォルト値はゼロ（0）になります。
The composite metric is based on bandwidth, delay, load, and reliability. MTU is not an attribute for calculating the composite metric, but carried in the vector metrics.
複合メトリックは、帯域幅、遅延、負荷、および信頼性に基づいています。 MTUは複合メトリックを計算するための属性ではなく、ベクトルメトリックで伝達されます。
One of the original goals of EIGRP was to offer and enhance routing solutions for IGRP. To achieve this, EIGRP used the same composite metric as IGRP, with the terms multiplied by 256 to change the metric from 24 bits to 32 bits.
EIGRPの当初の目標の1つは、IGRPのルーティングソリューションを提供および強化することでした。これを達成するために、EIGRPはIGRPと同じ複合メトリックを使用し、項を256倍してメトリックを24ビットから32ビットに変更しました。
EIGRP calculates the composite metric with the following formula:
EIGRPは、次の式を使用して複合メトリックを計算します。
metric = 256 * ({(K1*BW) + [(K2*BW)/(256-LOAD)] + (K3*DELAY)} *
(K5/(REL+K4)))
In this formula, Bandwidth (BW) is the lowest interface bandwidth along the path, and delay (DELAY) is the sum of all outbound interface delays along the path. Load (LOAD) and reliability (REL) values are expressed percentages with a value of 1 to 255.
この式では、帯域幅（BW）はパスに沿った最低のインターフェース帯域幅であり、遅延（DELAY）はパスに沿ったすべての送信インターフェース遅延の合計です。負荷（LOAD）と信頼性（REL）の値は、1〜255の値でパーセントで表されます。
Implementation note: Cisco IOS routers display reliability as a fraction of 255. That is, 255/255 is 100% reliability or a perfectly stable link; a value of 229/255 represents a 90% reliable link. Load is a value between 1 and 255. A load of 255/255 indicates a completely saturated link. A load of 127/255 represents a 50% saturated link. These values are not dynamically measured; they are only measured at the time a link changes.
実装上の注意：Cisco IOSルーターは、信頼性を255の一部として表示します。つまり、255/255は100％の信頼性または完全に安定したリンクです。 229/255という値は、90％の信頼できるリンクを表します。負荷は1〜255の値です。255/ 255の負荷は、完全に飽和したリンクを示します。 127/255の負荷は、50％飽和したリンクを表します。これらの値は動的に測定されません。リンクが変更されたときにのみ測定されます。
Bandwidth is the inverse minimum bandwidth (in kbps) of the path in bits per second scaled by a factor of 10^7. The formula for bandwidth is as follows:
帯域幅は、パスの逆最小帯域幅（kbps単位）で、ビット数/秒で10 ^ 7倍にスケーリングされています。帯域幅の式は次のとおりです。
(10^7)/BWmin
（10 ^ 7）/ BW分
Implementation note: When converting the real bandwidth to the composite bandwidth, truncate before applying the scaling factor. When converting the composite bandwidth to the real bandwidth, apply the scaling factor before the division and only then truncate.
実装上の注意：実際の帯域幅を複合帯域幅に変換するときは、スケーリング係数を適用する前に切り捨ててください。複合帯域幅を実際の帯域幅に変換するときは、除算の前に倍率を適用してから、切り捨てます。
The delay is the sum of the outgoing interface delay (in tens of microseconds) to the destination. A delay set to it maximum value (hexadecimal 0xFFFFFFFF) indicates that the network is unreachable. The formula for delay is as follows:
遅延は、宛先への発信インターフェース遅延（数十マイクロ秒）の合計です。最大値（16進数の0xFFFFFFFF）に設定された遅延は、ネットワークに到達できないことを示します。遅延の式は次のとおりです。
[sum of delays]
[遅延の合計]
The default composite metric, adjusted for scaling factors, for EIGRP is:
EIGRPの場合、スケーリング係数で調整されたデフォルトの複合メトリックは次のとおりです。
metric = 256 * { [(10^7)/ BWmin] + [sum of delays]}
Minimum Bandwidth (BWmin) is represented in kbps, and the "sum of delays" is represented in tens of microseconds. The bandwidth and delay for an Ethernet interface are 10 Mbps and 1 ms, respectively.
最小帯域幅（BWmin）はkbpsで表され、「遅延の合計」は数十マイクロ秒で表されます。イーサネットインターフェイスの帯域幅と遅延は、それぞれ10 Mbpsと1 msです。
The calculated EIGRP bandwidth (BW) metric is then:
計算されたEIGRP帯域幅（BW）メトリックは次のようになります。
256 * (10^7)/BW = 256 * {(10^7)/10,000}
= 256 * 1000
= 256,000
And the calculated EIGRP delay metric is then:
そして、計算されたEIGRP遅延メトリックは次のようになります。
256 * sum of delay = 256 * 100 * 10 microseconds
= 25,600 (in tens of microseconds)
For compatibility with Cisco products, the following table shows the times in nanoseconds EIGRP uses for bandwidth and delay.
シスコ製品との互換性のために、次の表は、EIGRPが帯域幅と遅延に使用する時間をナノ秒単位で示しています。
Bandwidth Classic Wide Metrics Interface
(kbps) Delay Delay Type
---------------------------------------------------------
9 500000000 500000000 Tunnel
56 20000000 20000000 56 kbps
64 20000000 20000000 DS0
1544 20000000 20000000 T1
2048 20000000 20000000 E1
10000 1000000 1000000 Ethernet
16000 630000 630000 TokRing16
45045 20000000 20000000 HSSI
100000 100000 100000 FDDI
100000 100000 100000 FastEthernet
155000 100000 100000 ATM 155 Mbps
1000000 10000 10000 GigaEthernet
2000000 10000 5000 2 Gig
5000000 10000 2000 5 Gig
10000000 10000 1000 10 Gig
20000000 10000 500 20 Gig
50000000 10000 200 50 Gig
100000000 10000 100 100 Gig
200000000 10000 50 200 Gig
500000000 10000 20 500 Gig
To enable EIGRP to perform the path selection for interfaces with high bandwidths, both the EIGRP packet and composite metric formula have been modified. This change allows EIGRP to choose paths based on the computed time (measured in picoseconds) information takes to travel though the links.
EIGRPが高帯域幅のインターフェイスのパス選択を実行できるようにするために、EIGRPパケットと複合メトリック式の両方が変更されました。この変更により、EIGRPは、情報がリンクを通過するのにかかる計算時間（ピコ秒で測定）に基づいてパスを選択できます。
EIGRP uses five "vector metrics": minimum Throughput, latency, load, reliability, and MTU. These values are calculated from destination to source as follows:
EIGRPは5つの「ベクトルメトリック」を使用します。最小スループット、レイテンシ、負荷、信頼性、およびMTUです。これらの値は、宛先からソースへ次のように計算されます。
o Throughput - Minimum value o Latency - accumulative o Load - maximum o Reliability - minimum o MTU - minimum o Hop count - accumulative
o スループット-最小値oレイテンシ-累積o負荷-最大o信頼性-最小o MTU-最小oホップカウント-累積
There are two additional values: Jitter and energy. These two values are accumulated from destination to source:
2つの追加の値があります：ジッタとエネルギー。これらの2つの値は、宛先からソースに累積されます。
o Jitter - accumulative o Energy - accumulative
o ジッタ-累積的oエネルギー-累積的
These Extended Attributes, as well as any future ones, will be controlled via K6. If K6 is non-zero, these will be additive to the path's composite metric. Higher Jitter or energy usage will result in paths that are worse than those that either do not monitor these attributes or that have lower values.
これらの拡張属性は、将来の属性と同様に、K6を介して制御されます。 K6がゼロ以外の場合、これらはパスの複合メトリックに追加されます。ジッタまたはエネルギー使用量が多いと、これらの属性を監視しないパスや値が小さいパスよりもパスが悪くなります。
EIGRP will not send these attributes if the router does not provide them. If the attributes are received, then EIGRP will use them in the metric calculation (based on K6) and will forward them with those routers values assumed to be "zero" and the accumulative values are forwarded unchanged.
EIGRPは、ルーターがこれらの属性を提供しない場合、これらの属性を送信しません。属性が受信されると、EIGRPはそれらを（K6に基づく）メトリック計算で使用し、「ゼロ」と見なされるルーター値でそれらを転送し、累積値は変更されずに転送されます。
The use of the vector metrics allows EIGRP to compute paths based on any of four (bandwidth, delay, reliability, and load) path selection schemes. The schemes are distinguished based on the choice of the key-measured network performance metric.
ベクトルメトリックを使用すると、EIGRPは4つの（帯域幅、遅延、信頼性、および負荷）パス選択スキームのいずれかに基づいてパスを計算できます。スキームは、主要なネットワークパフォーマンスメトリックの選択に基づいて区別されます。
Of these vector metric components, by default, only minimum Throughput and latency are traditionally used to compute the best path. Unlike most metrics, minimum Throughput is set to the minimum value of the entire path, and it does not reflect how many hops or low Throughput links are in the path, nor does it reflect the availability of parallel links. Latency is calculated based on one-way delays and is a cumulative value, which increases with each segment in the path.
これらのベクトルメトリックコンポーネントの中で、デフォルトでは、最小のスループットとレイテンシのみが伝統的に最適パスの計算に使用されます。ほとんどのメトリックとは異なり、最小スループットはパス全体の最小値に設定されており、パス内のホップ数や低スループットリンクの数や、並列リンクの可用性を反映していません。遅延は一方向の遅延に基づいて計算され、パスの各セグメントで増加する累積値です。
Network Designer note: When trying to manually influence EIGRP path selection though interface bandwidth/delay configuration, the modification of bandwidth is discouraged for following reasons: The change will only affect the path selection if the configured value is the lowest bandwidth over the entire path. Changing the bandwidth can have impact beyond affecting the EIGRP metrics. For example, Quality of Service (QoS) also looks at the bandwidth on an interface.
Network Designerの注意：インターフェイスの帯域幅/遅延の構成を介してEIGRPパスの選択に手動で影響を与えようとする場合、帯域幅の変更は次の理由により推奨されません：構成の値がパス全体で最低の帯域幅である場合、変更はパスの選択にのみ影響します。帯域幅の変更は、EIGRPメトリックに影響を与える以上の影響を与える可能性があります。たとえば、サービスの品質（QoS）はインターフェイスの帯域幅も調べます。
EIGRP throttles its packet transmissions so it will only use 50% of the configured bandwidth. Lowering the bandwidth can cause EIGRP to starve an adjacency, causing slow or failed convergence and control-plane operation.
EIGRPはパケット送信を抑制し、構成された帯域幅の50％のみを使用します。帯域幅を下げると、EIGRPが隣接関係を枯渇させ、収束やコントロールプレーンの動作が遅くなったり失敗したりする可能性があります。
Changing the delay does not impact other protocols, nor does it cause EIGRP to throttle back; changing the delay configured on a link only impacts metric calculation.
遅延を変更しても、他のプロトコルには影響しません。また、EIGRPがスロットルバックを引き起こすこともありません。リンクに設定された遅延を変更しても、メトリック計算にのみ影響します。
EIGRP uses a number of defined constants for conversion and calculation of metric values. These numbers are provided here for reference
EIGRPは、メトリック値の変換および計算のために、いくつかの定義済み定数を使用します。これらの番号は参照用にここに提供されています
EIGRP_BANDWIDTH 10,000,000 EIGRP_DELAY_PICO 1,000,000 EIGRP_INACCESSIBLE 0xFFFFFFFFFFFFFFFFLL EIGRP_MAX_HOPS 100 EIGRP_CLASSIC_SCALE 256 EIGRP_WIDE_SCALE 65536
EIGRP_BANDWIDTH 10,000,000 EIGRP_DELAY_PICO 1,000,000 EIGRP_INACCESSIBLE 0xFFFFFFFFFFFFFFFFLL EIGRP_MAX_HOPS 100 EIGRP_CLASSIC_SCALE 256 EIGRP_WIDE_SCALE 65536
When computing the metric using the above units, all capacity information will be normalized to kilobytes and picoseconds before being used. For example, delay is expressed in microseconds per kilobyte, and would be converted to kilobytes per second; likewise, energy would be expressed in power per kilobytes per second of usage.
上記の単位を使用してメトリックを計算する場合、すべての容量情報は、使用される前にキロバイトとピコ秒に正規化されます。たとえば、遅延はマイクロバイト/キロバイトで表され、キロバイト/秒に変換されます。同様に、エネルギーは使用量1秒あたりのキロバイトあたりの電力で表されます。
The formula for the conversion for Max-Throughput value directly from the interface without consideration of congestion-based effects is as follows:
輻輳に基づく影響を考慮せずに、インターフェースから直接最大スループット値を変換する式は次のとおりです。
(EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE)
Max-Throughput = K1 * ------------------------------------
Interface Bandwidth (kbps)
If K2 is used, the effect of congestion as a measure of load reported by the interface will be used to simulate the "available Throughput" by adjusting the maximum Throughput according to the formula:
K2を使用する場合、インターフェースによって報告される負荷の指標としての輻輳の影響を使用して、式に従って最大スループットを調整することにより、「使用可能なスループット」をシミュレートします。
K2 * Max-Throughput
Net-Throughput = Max-Throughput + ---------------------
256 - Load
K2 has the greatest effect on the metric occurs when the load increases beyond 90%.
負荷が90％を超えて増加すると、K2がメトリックに最大の影響を与えます。
Transmission times derived from physical interfaces MUST be n units of picoseconds, converted to picoseconds prior to being exchanged between neighbors, or used in the composite metric determination.
物理インターフェースから導出される送信時間は、ピコ秒のn単位である必要があり、近隣間で交換される前にピコ秒に変換されるか、または複合メトリックの決定に使用されます。
This includes delay values present in configuration-based commands (i.e., interface delay, redistribute, default-metric, route-map, etc.).
これには、構成ベースのコマンドに存在する遅延値が含まれます（つまり、インターフェース遅延、再配布、デフォルトメトリック、ルートマップなど）。
The delay value is then converted to a "latency" using the formula:
次に、遅延値は次の式を使用して「レイテンシ」に変換されます。
Delay * EIGRP_WIDE_SCALE
Latency = K3 * --------------------------
EIGRP_DELAY_PICO
K5
metric =[(K1*Net-Throughput) + Latency)+(K6*ExtAttr)] * ------
K4+Rel
By default, the path selection scheme used by EIGRP is a combination of Throughput and Latency where the selection is a product of total latency and minimum Throughput of all links along the path:
デフォルトでは、EIGRPで使用されるパス選択スキームは、スループットと遅延の組み合わせであり、選択は、パスに沿ったすべてのリンクの合計遅延と最小スループットの積です。
metric = (K1 * min(Throughput)) + (K3 * sum(Latency)) }
The IPv6 and IPv4 protocol identifier number spaces are common and will both use protocol identifier 88 [8] [9].
IPv6とIPv4のプロトコル識別子番号スペースは共通であり、両方ともプロトコル識別子88 [8] [9]を使用します。
EIGRP IPv4 will transmit HELLO packets using either the unicast destination of a neighbor or using a multicast host group address [7] with a source address EIGRP IPv4 multicast address [13].
EIGRP IPv4は、ネイバーのユニキャスト宛先を使用するか、ソースアドレスEIGRP IPv4マルチキャストアドレス[13]を持つマルチキャストホストグループアドレス[7]を使用して、HELLOパケットを送信します。
EIGRP IPv6 will transmit HELLO packets with a source address being the link-local address of the transmitting interface. Multicast HELLO packets will have a destination address of EIGRP IPv6 multicast address [14]. Unicast packets directed to a specific neighbor will contain the destination link-local address of the neighbor.
EIGRP IPv6は、送信元アドレスが送信インターフェイスのリンクローカルアドレスであるHELLOパケットを送信します。マルチキャストHELLOパケットの宛先アドレスはEIGRP IPv6マルチキャストアドレス[14]です。特定のネイバーに向けられたユニキャストパケットには、ネイバーの宛先リンクローカルアドレスが含まれます。
There is no requirement that two EIGRP IPv6 neighbors share a common prefix on their connecting interface. EIGRP IPv6 will check that a received HELLO contains a valid IPv6 link-local source address. Other HELLO processing will follow common EIGRP checks, including matching AS number and matching K-values.
2つのEIGRP IPv6ネイバーが接続インターフェイスで共通のプレフィックスを共有する必要はありません。 EIGRP IPv6は、受信したHELLOに有効なIPv6リンクローカルソースアドレスが含まれていることを確認します。他のHELLO処理は、一致するAS番号や一致するK値など、一般的なEIGRPチェックに従います。
The External Protocol field is an informational assignment to identify the originating routing protocol that this route was learned by. The following values are assigned:
External Protocolフィールドは、このルートが学習された元のルーティングプロトコルを識別するための情報割り当てです。次の値が割り当てられます。
Protocols Value IGRP 1 EIGRP 2 Static 3 RIP 4 HELLO 5 OSPF 6 ISIS 7 EGP 8 BGP 9 IDRP 10 Connected 11
プロトコル値IGRP 1 EIGRP 2静的3 RIP 4 HELLO 5 OSPF 6 ISIS 7 EGP 8 BGP 9 IDRP 10接続11
Destinations types are encoded according to the IANA address family number assignments. Currently only the following types are used:
宛先タイプは、IANAアドレスファミリー番号の割り当てに従ってエンコードされます。現在、次のタイプのみが使用されています。
AFI Description AFI Number
--------------------------------------
IP (IP version 4) 1
IP6 (IP version 6) 2
EIGRP Common Service Family 16384
EIGRP IPv4 Service Family 16385
EIGRP IPv6 Service Family 16386
EIGRP supports communities similar to the BGP Extended Communities RFC 4360 [4] extended type with Type field composed of 2 octets and Value field composed of 6 octets. Each Community is encoded as an 8-octet quantity, as follows:
EIGRPは、タイプフィールドが2オクテットで構成され、値フィールドが6オクテットで構成される、BGP拡張コミュニティRFC 4360 [4]拡張タイプと同様のコミュニティをサポートします。各コミュニティは、次のように8オクテットの量としてエンコードされます。
- Type field: 2 octets - Value field: Remaining octets
- タイプフィールド：2オクテット-値フィールド：残りのオクテット
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type high | Type low | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In addition to well-known communities supported by BGP (such as Site of Origin), EIGRP defines a number of additional Community values in the "Experimental Use" [5] range as follows:
BGPでサポートされている既知のコミュニティ（Site of Originなど）に加えて、EIGRPは「実験的使用」[5]の範囲で次のようにいくつかの追加のコミュニティ値を定義します。
Type high: 0x88 Type low:
高タイプ：0x88低タイプ：
Value Name Description
---------------------------------------------------------------
00 EXTCOMM_EIGRP EIGRP route information appended
01 EXTCOMM_DAD Data: AS + Delay
02 EXTCOMM_VRHB Vector: Reliability + Hop + BW
03 EXTCOMM_SRLM System: Reserve + Load + MTU
04 EXTCOMM_SAR System: Remote AS + Remote ID
05 EXTCOMM_RPM Remote: Protocol + Metric
06 EXTCOMM_VRR Vecmet: Rsvd + RouterID
The basic EIGRP packet payload format is identical for both IPv4 and IPv6, although there are some protocol-specific variations. Packets consist of a header, followed by a set of variable-length fields consisting of Type/Length/Value (TLV) triplets.
基本的なEIGRPパケットのペイロード形式は、IPv4とIPv6の両方で同じですが、プロトコル固有のバリエーションがいくつかあります。パケットはヘッダーで構成され、その後にタイプ/長さ/値（TLV）トリプレットで構成される可変長フィールドのセットが続きます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Header Version | Opcode | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Router ID | Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Header Version: EIGRP Packet Header Format version. Current Version is 2. This field is not the same as the TLV Version field.
ヘッダーバージョン：EIGRPパケットヘッダー形式のバージョン。現在のバージョンは2です。このフィールドは、TLVバージョンフィールドとは異なります。
Opcode: Indicates the type of the message. It will be one of the following values:
オペコード：メッセージのタイプを示します。次のいずれかの値になります。
EIGRP_OPC_UPDATE 1 EIGRP_OPC_REQUEST 2 EIGRP_OPC_QUERY 3 EIGRP_OPC_REPLY 4 EIGRP_OPC_HELLO 5 Reserved 6 (EIGRP_OPC_IPXSAP) Reserved 7 (EIGRP_OPC_PROBE) Reserved 8 (EIGRP_OPC_ACK) Reserved 9 EIGRP_OPC_SIAQUERY 10 EIGRP_OPC_SIAREPLY 11
EIGRP_OPC_UPDATE 1 EIGRP_OPC_REQUEST 2 EIGRP_OPC_QUERY 3 EIGRP_OPC_REPLY 4 EIGRP_OPC_HELLO 5予約済み6（EIGRP_OPC_IPXSAP）予約済み7（EIGRP_OPC_PROBE）予約済み8（EIGRP_OPC_ACK_OPCOPOPCAREOPCAREOPCAREOPCAREOPCAREOPCAREOPCRPOPCAREOPCRPOPCAREOPCRPOPCRPOPCRPOPCRPOPCRPOPCRPOPCRPCRPOPOPCSIRPCRPRP
Checksum: Each packet will include a checksum for the entire contents of the packet. The checksum will be the standard ones' complement of the ones' complement sum. For purposes of computing the checksum, the value of the checksum field is zero. The packet is discarded if the packet checksum fails.
チェックサム：各パケットには、パケットの内容全体のチェックサムが含まれます。チェックサムは、1の補数合計の標準の1の補数になります。チェックサムを計算するために、チェックサムフィールドの値はゼロです。パケットのチェックサムが失敗した場合、パケットは破棄されます。
Flags: Defines special handling of the packet. There are currently four defined flag bits.
フラグ：パケットの特別な処理を定義します。現在、4つのフラグビットが定義されています。
INIT-Flag (0x01): This bit is set in the initial UPDATE sent to a newly discovered neighbor. It instructs the neighbor to advertise its full set of routes.
INIT-Flag（0x01）：このビットは、新しく検出されたネイバーに送信される最初のUPDATEで設定されます。ネイバーにルートの完全なセットをアドバタイズするように指示します。
CR-Flag (0x02): This bit indicates that receivers should only accept the packet if they are in Conditionally Received mode. A router enters Conditionally Received mode when it receives and processes a HELLO packet with a SEQUENCE TLV present.
CR-Flag（0x02）：このビットは、受信者が条件付き受信モードの場合にのみパケットを受け入れる必要があることを示します。ルータは、シーケンスTLVが存在する状態でHELLOパケットを受信して処理すると、条件付き受信モードになります。
RS-Flag (0x04): The Restart flag is set in the HELLO and the UPDATE packets during the restart period. The router looks at the RS-Flag to detect if a neighbor is restarting. From the restarting routers perspective, if a neighboring router detects the RS-Flag set, it will maintain the adjacency, and will set the RS-Flag in its UPDATE packet to indicated it is doing a soft restart.
RS-Flag（0x04）：再起動フラグは、再起動期間中にHELLOおよびUPDATEパケットで設定されます。ルータはRS-Flagを調べて、ネイバーが再起動しているかどうかを検出します。再起動ルーターの観点から、隣接ルーターがRS-Flagセットを検出した場合、隣接ルーターは隣接関係を維持し、そのUPDATEパケットにRS-Flagを設定して、ソフト再起動を実行していることを示します。
EOT-Flag (0x08): The End-of-Table flag marks the end of the startup process with a neighbor. If the flag is set, it indicates the neighbor has completed sending all UPDATEs. At this point, the router will remove any stale routes learned from the neighbor prior to the restart event. A stale route is any route that existed before the restart and was not refreshed by the neighbor via and UPDATE.
EOT-Flag（0x08）：End-of-Tableフラグは、ネイバーとの起動プロセスの終わりを示します。フラグが設定されている場合は、ネイバーがすべてのUPDATEの送信を完了したことを示しています。この時点で、ルーターは再起動イベントの前にネイバーから学習した古いルートを削除します。失効したルートとは、再起動前に存在し、ネイバーおよびUPDATEを介してネイバーによって更新されなかったルートです。
Sequence Number: Each packet that is transmitted will have a 32-bit sequence number that is unique with respect to a sending router. A value of 0 means that an acknowledgment is not required.
シーケンス番号：送信される各パケットには、送信側ルーターに対して一意の32ビットのシーケンス番号が付けられます。値0は、確認が不要であることを意味します。
Acknowledgment Number: The 32-bit sequence number that is being acknowledged with respect to the receiver of the packet. If the value is 0, there is no acknowledgment present. A non-zero value can only be present in unicast-addressed packets. A HELLO packet with a non-zero ACK field should be decoded as an ACK packet rather than a HELLO packet.
確認番号：パケットの受信者に関して確認されている32ビットのシーケンス番号。値が0の場合、確認応答はありません。ゼロ以外の値は、ユニキャストアドレス指定されたパケットにのみ存在できます。ゼロ以外のACKフィールドを持つHELLOパケットは、HELLOパケットではなくACKパケットとしてデコードする必要があります。
Virtual Router Identifier (VRID): A 16-bit number that identifies the virtual router with which this packet is associated. Packets received with an unknown, or unsupported, value will be discarded.
仮想ルーター識別子（VRID）：このパケットが関連付けられている仮想ルーターを識別する16ビットの番号。不明な、またはサポートされていない値で受信されたパケットは破棄されます。
Value Range Usage 0x0000 Unicast Address Family 0x0001 Multicast Address Family 0x0002-0x7FFF Reserved 0x8000 Unicast Service Family 0x8001-0xFFFF Reserved
値の範囲使用法0x0000ユニキャストアドレスファミリ0x0001マルチキャストアドレスファミリ0x0002-0x7FFF予約済み0x8000ユニキャストサービスファミリ0x8001-0xFFFF予約済み
Autonomous System Number: 16-bit unsigned number of the sending system. This field is indirectly used as an authentication value. That is, a router that receives and accepts a packet from a neighbor must have the same AS number or the packet is ignored. The range of valid AS numbers is 1 through 65,535.
自律システム番号：送信システムの16ビット符号なし番号。このフィールドは、認証値として間接的に使用されます。つまり、ネイバーからパケットを受信して受け入れるルータは、同じAS番号を持つ必要があります。そうでない場合、パケットは無視されます。有効なAS番号の範囲は1〜65,535です。
The contents of each packet can contain a variable number of fields. Each field will be tagged and include a length field. This allows for newer versions of software to add capabilities and coexist with old versions of software in the same configuration. Fields that are tagged and not recognized can be skipped over. Another advantage of this encoding scheme is that it allows multiple network-layer protocols to carry independent information. Therefore, if it is later decided to implement a single "integrated" protocol, this can be done.
各パケットの内容には、可変数のフィールドを含めることができます。各フィールドにはタグが付けられ、長さフィールドが含まれます。これにより、新しいバージョンのソフトウェアで機能を追加し、同じ構成で古いバージョンのソフトウェアと共存させることができます。タグが付けられ、認識されないフィールドはスキップできます。このエンコード方式のもう1つの利点は、複数のネットワーク層プロトコルが独立した情報を伝送できることです。したがって、後で単一の「統合」プロトコルを実装することが決定された場合、これを行うことができます。
The format of a {type, length, value} (TLV) is encoded as follows:
{type、length、value}（TLV）の形式は次のようにエンコードされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type high | Type low | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type values are the ones defined below. The length value specifies the length in octets of the type, length, and value fields. TLVs can appear in a packet in any order, and there are no interdependencies among them.
タイプ値は、以下に定義されているものです。長さの値は、タイプ、長さ、および値フィールドのオクテットの長さを指定します。 TLVは任意の順序でパケットに表示でき、相互に依存関係はありません。
Malformed TLVs contained in EIGRP messages are handled by silently discarding the containing message. A TLV is malformed if the TLV Length is invalid or if the TLV extends beyond the end of the containing message.
EIGRPメッセージに含まれる不正なTLVは、含まれているメッセージをサイレントに破棄することによって処理されます。 TLVの長さが無効である場合、またはTLVがメッセージの最後を超えている場合、TLVは不正な形式です。
The type field is structured as follows: Type High: 1 octet that defines the protocol classification:
タイプフィールドは次のように構成されています。タイプ高：プロトコル分類を定義する1オクテット：
Protocol ID VERSION General 0x00 1.2 IPv4 0x01 1.2 IPv6 0x04 1.2 SAF 0x05 3.0 Multiprotocol 0x06 2.0
プロトコルID VERSION一般0x00 1.2 IPv4 0x01 1.2 IPv6 0x04 1.2 SAF 0x05 3.0マルチプロトコル0x06 2.0
Type Low: 1 octet that defines the TLV Opcode; see TLV Definitions in Section 3.
タイプLow：TLVオペコードを定義する1オクテット。セクション3のTLV定義を参照してください。
The Length field is a 2-octet unsigned number, which indicates the length of the TLV. The value includes the Type and Length fields.
長さフィールドは、TLVの長さを示す2オクテットの符号なし数値です。値には、「タイプ」フィールドと「長さ」フィールドが含まれます。
The Value field is a multi-octet field containing the payload for the TLV.
Valueフィールドは、TLVのペイロードを含むマルチオクテットフィールドです。
Ver 1.2 Ver 2.0
PARAMETER_TYPE 0x0001 0x0001
AUTHENTICATION_TYPE 0x0002 0x0002
SEQUENCE_TYPE 0x0003 0x0003
SOFTWARE_VERSION_TYPE 0x0004 0x0004
MULTICAST_SEQUENCE_TYPE 0x0005 0x0005
PEER_INFORMATION_TYPE 0x0006 0x0006
PEER_TERMINATION_TYPE 0x0007 0x0007
PEER_TID_LIST_TYPE --- 0x0008
This TLV is used in HELLO packets to convey the EIGRP metric coefficient values: noted as "K-values" as well as the Hold Time values. This TLV is also used in an initial UPDATE packet when a neighbor is discovered.
このTLVは、HELLOパケットでEIGRPメトリック係数値を伝えるために使用されます。「K値」およびホールドタイム値として示されます。このTLVは、ネイバーが検出されたときの最初のUPDATEパケットでも使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0001 | 0x000C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K1 | K2 | K3 | K4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| K5 | K6 | Hold Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
K-values: The K-values associated with the EIGRP composite metric equation. The default values for weights are:
K値：EIGRP複合メトリック方程式に関連付けられたK値。重みのデフォルト値は次のとおりです。
K1 - 1 K2 - 0 K3 - 1 K4 - 0 K5 - 0 K6 - 0
K1-1 K2-0 K3-1 K4-0 K5-0 K6-0
Hold Time: The amount of time in seconds that a receiving router should consider the sending neighbor valid. A valid neighbor is one that is able to forward packets and participates in EIGRP. A router that considers a neighbor valid will store all routing information advertised by the neighbor.
保持時間：受信側ルーターが送信側ネイバーを有効であると見なす時間（秒単位）。有効なネイバーは、パケットを転送でき、EIGRPに参加できるネイバーです。ネイバーが有効であると見なすルータは、ネイバーによってアドバタイズされたすべてのルーティング情報を保存します。
This TLV may be used in any EIGRP packet and conveys the authentication type and data used. Routers receiving a mismatch in authentication shall discard the packet.
このTLVは任意のEIGRPパケットで使用でき、使用される認証タイプとデータを伝達します。認証の不一致を受信したルーターは、パケットを破棄します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0002 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Type | Auth Length | Auth Data (Variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Authentication Type: The type of authentication used.
Authentication Length: The length, measured in octets, of the individual authentication.
認証の長さ：オクテットで測定された、個々の認証の長さ。
Authentication Data: Variable-length field reflected by "Auth Length", which is dependent on the type of authentication used. Multiple authentication types can be present in a single AUTHENTICATION_TYPE TLV.
認証データ：「Auth Length」に反映される可変長フィールド。これは、使用される認証のタイプによって異なります。 1つのAUTHENTICATION_TYPE TLVに複数の認証タイプを含めることができます。
MD5 Authentication will use Auth Type code 0x02, and the Auth Data will be the MD5 Hash value.
MD5認証は認証タイプコード0x02を使用し、認証データはMD5ハッシュ値になります。
SHA2-256 Authentication will use Type code 0x03, and the Auth Data will be the 256-bit SHA2 [6] Hash value.
SHA2-256認証はタイプコード0x03を使用し、認証データは256ビットのSHA2 [6]ハッシュ値になります。
This TLV is used for a sender to tell receivers to not accept packets with the CR-Flag set. This is used to order multicast and unicast addressed packets.
このTLVは、CRフラグが設定されたパケットを受け入れないように送信者に通知するために使用されます。これは、マルチキャストおよびユニキャストのアドレス指定されたパケットを順序付けるために使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0003 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Address Length | Protocol Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Address Length and Protocol Address will be repeated one or more times based on the Length field.
アドレス長とプロトコルアドレスは、長さフィールドに基づいて1回以上繰り返されます。
Address Length: Number of octets for the address that follows. For IPv4, the value is 4. For IPv6, it is 16. For AppleTalk, the value is 4; for Novell IPX, the value is 10 (both are no longer in use).
アドレス長：続くアドレスのオクテット数。 IPv4の場合、値は4です。IPv6の場合、値は16です。AppleTalkの場合、値は4です。 Novell IPXの場合、値は10です（どちらも使用されなくなりました）。
Protocol Address: Neighbor address on interface in which the HELLO with SEQUENCE TLV is sent. Each address listed in the HELLO packet is a neighbor that should not enter Conditionally Received mode.
プロトコルアドレス：HELLO with SEQUENCE TLVが送信されるインターフェイスのネイバーアドレス。 HELLOパケットにリストされている各アドレスは、条件付き受信モードに入るべきではないネイバーです。
Field Length Vender OS major version 1 Vender OS minor version 1 EIGRP major revision 1 EIGRP minor revision 1
フィールド長Vender OSメジャーバージョン1 Vender OSマイナーバージョン1 EIGRPメジャーリビジョン1 EIGRPマイナーリビジョン1
The EIGRP TLV Version fields are used to determine TLV format versions. Routers using Version 1.2 TLVs do not understand Version 2.0 TLVs, therefore Version 2.0 routers must send the packet with both TLV formats in a mixed network.
EIGRP TLVバージョンフィールドは、TLV形式のバージョンを判別するために使用されます。バージョン1.2 TLVを使用するルーターは、バージョン2.0 TLVを認識しないため、バージョン2.0ルーターは両方のTLV形式のパケットを混合ネットワークで送信する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0004 | 0x000C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vendor Major V.|Vendor Minor V.| EIGRP Major V.| EIGRP Minor V.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The next multicast SEQUENCE TLV.
次のマルチキャストSEQUENCE TLV。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0005 | 0x0008 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is reserved, and not part of this document.
このTLVは予約されており、このドキュメントの一部ではありません。
This TLV is used in HELLO packets to notify the list of neighbor(s) the router has reset the adjacency. This TLV is used in HELLO packets to notify the list of neighbors that the router has reset the adjacency. This is used anytime a router needs to reset an adjacency, or signal an adjacency it is going down.
このTLVは、ルータが隣接関係をリセットしたネイバーのリストに通知するために、HELLOパケットで使用されます。このTLVは、ルータが隣接関係をリセットしたことをネイバーのリストに通知するために、HELLOパケットで使用されます。これは、ルータが隣接関係をリセットしたり、隣接関係がダウンしていることを通知したりする必要があるときにいつでも使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0007 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address List (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Implementation note: Older Cisco routers implement this using the "Parameters TLV" with all K-values set to 255 (except K6).
実装メモ：古いCiscoルーターは、「パラメーターTLV」を使用してこれを実装し、すべてのK値を255に設定します（K6を除く）。
List of sub-topology identifiers, including the Base Topology, supported by the router.
ルータでサポートされている、サブトポロジIDのリスト（ベーストポロジを含む）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0008 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Topology Identification List (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If this information changes from the last state, it means either a new topology was added or an existing topology was removed. This TLV is ignored until the three-way handshake has finished
この情報が最後の状態から変更された場合は、新しいトポロジが追加されたか、既存のトポロジが削除されたことを意味します。このTLVは、3ウェイハンドシェイクが完了するまで無視されます。
When the TID list is received, it compares the list to the previous list sent. If a TID is found that does not previously exist, the TID is added to the neighbor's topology list, and the existing sub-topology is sent to the peer.
TIDリストが受信されると、それは送信された前のリストとリストを比較します。以前に存在しなかったTIDが見つかった場合、TIDはネイバーのトポロジリストに追加され、既存のサブトポロジがピアに送信されます。
If a TID that was in a previous list is not found, the TID is removed from the neighbor's topology list and all routes learned though that neighbor for that sub-topology are removed from the topology table.
前のリストにあったTIDが見つからない場合、TIDはネイバーのトポロジリストから削除され、そのサブトポロジのそのネイバーを介して学習されたすべてのルートがトポロジテーブルから削除されます。
EIGRP transports a number of flags with in the TLVs to indicate addition route state information. These bits are defined as follows:
EIGRPは、追加のルート状態情報を示すために、TLV内で多数のフラグを転送します。これらのビットは次のように定義されています。
Flags Field
-----------
Source Withdraw (Bit 0) - Indicates if the router that is the
original source of the destination is withdrawing the route from the
network or if the destination is lost due as a result of a network
failure.
Candidate Default (CD) (Bit 1) - Set to indicate the destination should be regarded as a candidate for the default route. An EIGRP default route is selected from all the advertised candidate default routes with the smallest metric.
候補デフォルト（CD）（ビット1）-宛先をデフォルトルートの候補と見なす必要があることを示すために設定します。 EIGRPデフォルトルートは、最小メトリックでアドバタイズされたすべての候補デフォルトルートから選択されます。
ACTIVE (Bit 2) - Indicates if the route is in the ACTIVE State.
ACTIVE（ビット2）-ルートがアクティブ状態かどうかを示します。
The handling of bandwidth and delay for Classic TLVs is encoded in the packet "scaled" form relative to how they are represented on the physical link.
クラシックTLVの帯域幅と遅延の処理は、物理リンク上での表現方法に応じて、「スケーリングされた」パケット形式でエンコードされます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scaled Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scaled Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reliability | Load | Internal Tag | Flags Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Scaled Delay: An administrative parameter assigned statically on a per-interface-type basis to represent the time it takes along an unloaded path. This is expressed in units of tens of microseconds divvied by 256. A delay of 0xFFFFFFFF indicates an unreachable route.
スケーリングされた遅延：アンロードされたパスにかかる時間を表すために、インターフェイスタイプごとに静的に割り当てられた管理パラメーター。これは、256で割った数十マイクロ秒の単位で表されます。0xFFFFFFFFの遅延は、到達できないルートを示します。
Scaled Bandwidth: The path bandwidth measured in bits per second. In units of 2,560,000,000/kbps.
スケーリングされた帯域幅：ビット/秒で測定されたパス帯域幅。 2,560,000,000 / kbpsの単位。
MTU: The minimum MTU size for the path to the destination.
MTU：宛先へのパスの最小MTUサイズ。
Hop Count: The number of router traversals to the destination.
ホップ数：宛先へのルータートラバーサルの数。
Reliability: The current error rate for the path, measured as an error percentage. A value of 255 indicates 100% reliability
信頼性：パスの現在のエラー率。エラー率として測定されます。 255の値は100％の信頼性を示します
Load: The load utilization of the path to the destination, measured as a percentage. A value of 255 indicates 100% load.
負荷：宛先へのパスの負荷使用率。パーセンテージで測定されます。値255は、100％の負荷を示します。
Internal-Tag: A tag assigned by the network administrator that is untouched by EIGRP. This allows a network administrator to filter routes in other EIGRP border routers based on this value.
内部タグ：EIGRPによって変更されない、ネットワーク管理者によって割り当てられたタグ。これにより、ネットワーク管理者は、この値に基づいて他のEIGRPボーダールーターのルートをフィルタリングできます。
Flags Field: See Section 6.8.1.
フラグフィールド：セクション6.8.1を参照してください。
Additional routing information so provided for destinations outside of the EIGRP AS as follows:
EIGRP ASの外部の宛先に提供される追加のルーティング情報は、次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Identifier (RID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Autonomous System (AS) Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Protocol Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Extern Protocol| Flags Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router Identifier (RID): A 32-bit number provided by the router sourcing the information to uniquely identify it as the source.
ルーター識別子（RID）：ルーターが提供する32ビットの番号で、ソースとして一意に識別するための情報を提供します。
External Autonomous System (AS) Number: A 32-bit number indicating the external AS of which the sending router is a member. If the source protocol is EIGRP, this field will be the [VRID, AS] pair. If the external protocol does not have an AS, other information can be used (for example, Cisco uses process-id for OSPF).
外部自律システム（AS）番号：送信ルーターがメンバーになっている外部ASを示す32ビットの番号。ソースプロトコルがEIGRPの場合、このフィールドは[VRID、AS]ペアになります。外部プロトコルにASがない場合は、他の情報を使用できます（たとえば、シスコはOSPFにプロセスIDを使用します）。
Administrative Tag: A tag assigned by the network administrator that is untouched by EIGRP. This allows a network administrator to filter routes in other EIGRP border routers based on this value.
管理タグ：EIGRPによって変更されない、ネットワーク管理者によって割り当てられたタグ。これにより、ネットワーク管理者は、この値に基づいて他のEIGRPボーダールーターのルートをフィルタリングできます。
External Protocol Metric: 32-bit value of the composite metric that resides in the routing table as learned by the foreign protocol. If the External Protocol is IGRP or another EIGRP routing process, the value can optionally be the composite metric or 0, and the metric information is stored in the metric section.
外部プロトコルメトリック：外部プロトコルによって学習されたルーティングテーブルに存在する複合メトリックの32ビット値。外部プロトコルがIGRPまたは別のEIGRPルーティングプロセスである場合、値はオプションで複合メトリックまたは0にすることができ、メトリック情報はメトリックセクションに格納されます。
External Protocol: Contains an enumerated value defined in Section 6.2 to identify the routing protocol (external protocol) redistributing the route.
外部プロトコル：セクション6.2で定義された列挙値を含み、ルートを再配布するルーティングプロトコル（外部プロトコル）を識別します。
Flags Field: See Section 6.8.1
フラグフィールド：セクション6.8.1を参照
EIGRP carries destination in a compressed form, where the number of bits significant in the variable-length address field are indicated in a counter.
EIGRPは宛先を圧縮形式で伝送します。可変長アドレスフィールドの有効ビット数はカウンターに示されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subnet Mask | Destination Address (variable length) |
| Bit Count | ((Bit Count - 1) / 8) + 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subnet Mask Bit Count: 8-bit value used to indicate the number of bits in the subnet mask. A value of 0 indicates the default network, and no address is present.
サブネットマスクビット数：サブネットマスクのビット数を示すために使用される8ビット値。値0はデフォルトのネットワークを示し、アドレスは存在しません。
Destination Address: A variable-length field used to carry the destination address. The length is determined by the number of consecutive bits in the destination address. The formula to calculate the length is address-family dependent:
宛先アドレス：宛先アドレスを運ぶために使用される可変長フィールド。長さは、宛先アドレスの連続するビット数によって決まります。長さを計算する式はアドレスファミリによって異なります。
IPv4: ((Bit Count - 1) / 8) + 1
IPv6: (Bit Count == 128) ? 16 : ((x / 8) + 1)
INTERNAL_TYPE 0x0102 EXTERNAL_TYPE 0x0103 COMMUNITY_TYPE 0x0104
INTERNAL_TYPE 0x0102 EXTERNAL_TYPE 0x0103 COMMUNITY_TYPE 0x0104
This TLV conveys IPv4 destination and associated metric information for IPv4 networks. Routes advertised in this TLV are network interfaces that EIGRP is configured on as well as networks that are learned via other routers running EIGRP.
このTLVは、IPv4宛先および関連するIPv4ネットワークのメトリック情報を伝達します。このTLVでアドバタイズされるルートは、EIGRPが構成されているネットワークインターフェイスと、EIGRPを実行している他のルーターを介して学習されるネットワークです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x02 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-Hop Forwarding Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vector Metric Section (see Section 6.8.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Destination Section |
| IPv4 Address (variable length) |
| (see Section 6.8.4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next-Hop Forwarding Address: IPv4 address represented by four 8-bit values (total 4 octets). If the value is zero (0), the IPv4 address from the received IPv4 header is used as the next hop for the route. Otherwise, the specified IPv4 address will be used.
ネクストホップ転送アドレス：4つの8ビット値（合計4オクテット）で表されるIPv4アドレス。値がゼロ（0）の場合、受信したIPv4ヘッダーからのIPv4アドレスがルートのネクストホップとして使用されます。それ以外の場合は、指定されたIPv4アドレスが使用されます。
Vector Metric Section: The vector metrics for destinations contained in this TLV. See the description of "metric encoding" in Section 6.8.2.
ベクトルメトリックセクション：このTLVに含まれる宛先のベクトルメトリック。セクション6.8.2の「メトリックエンコーディング」の説明を参照してください。
Destination Section: The network/subnet/host destination address being requested. See the description of "destination" in Section 6.8.4.
宛先セクション：要求されているネットワーク/サブネット/ホスト宛先アドレス。 6.8.4項の「宛先」の説明を参照してください。
This TLV conveys IPv4 destination and metric information for routes learned by other routing protocols that EIGRP injects into the AS. Available with this information is the identity of the routing protocol that created the route, the external metric, the AS number, an indicator if it should be marked as part of the EIGRP AS, and a network-administrator tag used for route filtering at EIGRP AS boundaries.
このTLVは、EIGRPがASに挿入する他のルーティングプロトコルによって学習されたルートのIPv4宛先およびメトリック情報を伝達します。この情報で利用できるのは、ルートを作成したルーティングプロトコルのID、外部メトリック、AS番号、EIGRP ASの一部としてマークする必要があるかどうかのインジケータ、およびEIGRPでのルートフィルタリングに使用されるネットワーク管理者タグです。 AS境界。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x03 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-Hop Forwarding Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exterior Section (see Section 6.8.3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vector Metric Section (see Section 6.8.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Destination Section |
| IPv4 Address (variable length) |
| (see Section 6.8.4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next-Hop Forwarding Address: IPv4 address represented by four 8-bit values (total 4 octets). If the value is zero (0), the IPv4 address from the received IPv4 header is used as the next hop for the route. Otherwise, the specified IPv4 address will be used.
ネクストホップ転送アドレス：4つの8ビット値（合計4オクテット）で表されるIPv4アドレス。値がゼロ（0）の場合、受信したIPv4ヘッダーからのIPv4アドレスがルートのネクストホップとして使用されます。それ以外の場合は、指定されたIPv4アドレスが使用されます。
Exterior Section: Additional routing information provided for a destination that is outside of the AS and that has been redistributed into the EIGRP. See the description of "exterior encoding" in Section 6.8.3.
外部セクション：ASの外部にあり、EIGRPに再配布された宛先に提供される追加のルーティング情報。 6.8.3項の「外部エンコーディング」の説明を参照してください。
Vector Metric Section: Vector metrics for destinations contained in this TLV. See the description of "metric encoding" in Section 6.8.2.
ベクトルメトリックセクション：このTLVに含まれる宛先のベクトルメトリック。セクション6.8.2の「メトリックエンコーディング」の説明を参照してください。
Destination Section: The network/subnet/host destination address being requested. See the description of "destination" in Section 6.8.4.
宛先セクション：要求されているネットワーク/サブネット/ホスト宛先アドレス。 6.8.4項の「宛先」の説明を参照してください。
This TLV is used to provide community tags for specific IPv4 destinations.
このTLVは、特定のIPv4宛先にコミュニティタグを提供するために使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Destination |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Community Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community List |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Destination: The IPv4 address with which the community information should be stored.
IPv4宛先：コミュニティ情報の保存に使用するIPv4アドレス。
Community Length: A 2-octet unsigned number that indicates the length of the Community List. The length does not include the IPv4 Address, Reserved, or Length fields.
コミュニティの長さ：コミュニティリストの長さを示す2オクテットの符号なし数値。長さには、IPv4アドレス、予約済み、または長さのフィールドは含まれません。
Community List: One or more 8-octet EIGRP communities, as defined in Section 6.4.
コミュニティリスト：セクション6.4で定義されている1つ以上の8オクテットEIGRPコミュニティ。
INTERNAL_TYPE 0x0402 EXTERNAL_TYPE 0x0403 COMMUNITY_TYPE 0x0404
INTERNAL_TYPE 0x0402 EXTERNAL_TYPE 0x0403 COMMUNITY_TYPE 0x0404
This TLV conveys the IPv6 destination and associated metric information for IPv6 networks. Routes advertised in this TLV are network interfaces that EIGRP is configured on as well as networks that are learned via other routers running EIGRP.
このTLVは、IPv6宛先と、IPv6ネットワークの関連するメトリック情報を伝達します。このTLVでアドバタイズされるルートは、EIGRPが構成されているネットワークインターフェイスと、EIGRPを実行している他のルーターを介して学習されるネットワークです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x04 | 0x02 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Next-Hop Forwarding Address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vector Metric Section (see Section 6.8.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Destination Section |
| IPv6 Address (variable length) |
| (see Section 6.8.4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next-Hop Forwarding Address: This IPv6 address is represented by eight groups of 16-bit values (total 16 octets). If the value is zero (0), the IPv6 address from the received IPv6 header is used as the next hop for the route. Otherwise, the specified IPv6 address will be used.
ネクストホップ転送アドレス：このIPv6アドレスは、16ビット値の8つのグループ（合計16オクテット）で表されます。値がゼロ（0）の場合、受信したIPv6ヘッダーのIPv6アドレスがルートのネクストホップとして使用されます。それ以外の場合は、指定されたIPv6アドレスが使用されます。
Vector Metric Section: Vector metrics for destinations contained in this TLV. See the description of "metric encoding" in Section 6.8.2.
ベクトルメトリックセクション：このTLVに含まれる宛先のベクトルメトリック。セクション6.8.2の「メトリックエンコーディング」の説明を参照してください。
Destination Section: The network/subnet/host destination address being requested. See the description of "destination" in Section 6.8.4.
宛先セクション：要求されているネットワーク/サブネット/ホスト宛先アドレス。 6.8.4項の「宛先」の説明を参照してください。
This TLV conveys IPv6 destination and metric information for routes learned by other routing protocols that EIGRP injects into the topology. Available with this information is the identity of the routing protocol that created the route, the external metric, the AS number, an indicator if it should be marked as part of the EIGRP AS, and a network administrator tag used for route filtering at EIGRP AS boundaries.
このTLVは、EIGRPがトポロジに挿入する他のルーティングプロトコルによって学習されたルートのIPv6宛先およびメトリック情報を伝達します。この情報で利用できるのは、ルートを作成したルーティングプロトコルのID、外部メトリック、AS番号、EIGRP ASの一部としてマークする必要があるかどうかのインジケーター、およびEIGRP ASでのルートフィルタリングに使用されるネットワーク管理者タグです。境界。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x04 | 0x03 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Next-Hop Forwarding Address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exterior Section (see Section 6.8.3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vector Metric Section (see Section 6.8.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Destination Section |
| IPv6 Address (variable length) |
| (see Section 6.8.4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next-Hop Forwarding Address: IPv6 address is represented by eight groups of 16-bit values (total 16 octets). If the value is zero (0), the IPv6 address from the received IPv6 header is used as the next hop for the route. Otherwise, the specified IPv6 address will be used.
ネクストホップ転送アドレス：IPv6アドレスは、16ビット値の8つのグループ（合計16オクテット）で表されます。値がゼロ（0）の場合、受信したIPv6ヘッダーのIPv6アドレスがルートのネクストホップとして使用されます。それ以外の場合は、指定されたIPv6アドレスが使用されます。
Exterior Section: Additional routing information provided for a destination that is outside of the AS and that has been redistributed into the EIGRP. See the description of "exterior encoding" in Section 6.8.3.
外部セクション：ASの外部にあり、EIGRPに再配布された宛先に提供される追加のルーティング情報。 6.8.3項の「外部エンコーディング」の説明を参照してください。
Vector Metric Section: vector metrics for destinations contained in this TLV. See the description of "metric encoding" in Section 6.8.2.
ベクトルメトリックセクション：このTLVに含まれる宛先のベクトルメトリック。セクション6.8.2の「メトリックエンコーディング」の説明を参照してください。
Destination Section: The network/subnet/host destination address being requested. See the description of "destination" in Section 6.8.4.
宛先セクション：要求されているネットワーク/サブネット/ホスト宛先アドレス。 6.8.4項の「宛先」の説明を参照してください。
This TLV is used to provide community tags for specific IPv4 destinations.
このTLVは、特定のIPv4宛先にコミュニティタグを提供するために使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x04 | 0x04 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Community Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Community List |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination: The IPv6 address with which the community information should be stored.
宛先：コミュニティ情報の保存に使用するIPv6アドレス。
Community Length: A 2-octet unsigned number that indicates the length of the Community List. The length does not include the IPv6 Address, Reserved, or Length fields.
コミュニティの長さ：コミュニティリストの長さを示す2オクテットの符号なし数値。長さには、IPv6アドレス、予約済み、または長さのフィールドは含まれません。
Community List: One or more 8-octet EIGRP communities, as defined in Section 6.4.
コミュニティリスト：セクション6.4で定義されている1つ以上の8オクテットEIGRPコミュニティ。
This TLV conveys topology and associated metric information.
このTLVは、トポロジおよび関連するメトリック情報を伝達します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Header Version | Opcode | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Router ID | Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Header Encoding |
| (see Section 6.9.1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wide Metric Encoding |
| (see Section 6.9.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Descriptor |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
There has been a long-standing requirement for EIGRP to support routing technologies, such as multi-topologies, and to provide the ability to carry destination information independent of the transport. To accomplish this, a Vector has been extended to have a new "Header Extension Header" section. This is a variable-length field and, at a minimum, it will support the following fields:
EIGRPには、マルチトポロジなどのルーティングテクノロジーをサポートし、転送とは無関係に宛先情報を伝送する機能を提供するという長年の要件がありました。これを実現するために、ベクターは新しい「ヘッダー拡張ヘッダー」セクションを持つように拡張されました。これは可変長フィールドであり、少なくとも次のフィールドをサポートします。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type High | Type Low | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | TID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Identifier (RID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The available fields are:
TYPE - Topology TLVs have the following TYPE codes: Type High: 0x06 Type Low: REQUEST_TYPE 0x01 INTERNAL_TYPE 0x02 EXTERNAL_TYPE 0x03
TYPE-トポロジーTLVには次のTYPEコードがあります：タイプ高：0x06タイプ低：REQUEST_TYPE 0x01 INTERNAL_TYPE 0x02 EXTERNAL_TYPE 0x03
Router Identifier (RID): A 32-bit number provided by the router sourcing the information to uniquely identify it as the source.
ルーター識別子（RID）：ルーターが提供する32ビットの番号で、ソースとして一意に識別するための情報を提供します。
Multiprotocol TLVs will provide an extendable section of metric information, which is not used for the primary routing compilation. Additional per-path information is included to enable per-path cost calculations in the future. Use of the per-path costing along with the VID/TID will prove a complete solution for multidimensional routing.
マルチプロトコルTLVは、メトリック情報の拡張可能なセクションを提供します。これは、プライマリルーティングのコンパイルには使用されません。パスごとのコスト計算を将来可能にするために、追加のパスごとの情報が含まれています。 VID / TIDと共にパスごとのコスト計算を使用すると、多次元ルーティングの完全なソリューションが証明されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset | Priority | Reliability | Load |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delay |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Opaque Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Attributes |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
フィールドは次のとおりです。
Offset: Number of 16-bit words in the Extended Attribute section that are used to determine the start of the destination information. A value of zero indicates no Extended Attributes are attached.
オフセット：宛先情報の開始を決定するために使用される拡張属性セクション内の16ビットワードの数。ゼロの値は、拡張属性が付加されていないことを示します。
Priority: Priority of the prefix when processing a route. In an AS using priority values, a destination with a higher priority receives preferential treatment and is serviced before a destination with a lower priority. A value of zero indicates no priority is set.
優先度：ルートを処理するときのプレフィックスの優先度。プライオリティ値を使用するASでは、プライオリティの高い宛先が優先的に処理され、プライオリティの低い宛先の前にサービスされます。ゼロの値は、優先順位が設定されていないことを示します。
Reliability: The current error rate for the path. Measured as an error percentage. A value of 255 indicates 100% reliability
信頼性：パスの現在のエラー率。エラー率として測定されます。 255の値は100％の信頼性を示します
Load: The load utilization of the path to the destination, measured as a percentage. A value of 255 indicates 100% load.
負荷：宛先へのパスの負荷使用率。パーセンテージで測定されます。値255は、100％の負荷を示します。
MTU: The minimum MTU size for the path to the destination. Not used in metric calculation but available to underlying protocols
MTU：宛先へのパスの最小MTUサイズ。メトリック計算では使用されませんが、基礎となるプロトコルで使用できます
Hop Count: The number of router traversals to the destination.
ホップ数：宛先へのルータートラバーサルの数。
Delay: The one-way latency along an unloaded path to the destination expressed in units of picoseconds per kilobit. This number is not scaled; a value of 0xFFFFFFFFFFFF indicates an unreachable route.
遅延：キロビットあたりのピコ秒の単位で表される、宛先へのアンロードパスに沿った一方向の遅延。この数はスケーリングされません。値0xFFFFFFFFFFFFは、到達不能なルートを示します。
Bandwidth: The path bandwidth measured in kilobit per second as presented by the interface. This number is not scaled; a value of 0xFFFFFFFFFFFF indicates an unreachable route.
帯域幅：インターフェースによって提示される、キロビット/秒で測定されたパス帯域幅。この数はスケーリングされません。値0xFFFFFFFFFFFFは、到達不能なルートを示します。
Reserved: Transmitted as 0x0000.
予約済み：0x0000として送信。
Opaque Flags: 16-bit protocol-specific flags. Values currently defined by Cisco are:
Opaque Flags：16ビットのプロトコル固有のフラグ。現在シスコが定義している値は次のとおりです。
OPAQUE_SRCWD 0x01 Route Source Withdraw OPAQUE_CD 0x02 Candidate default route OPAQUE_ACTIVE 0x04 Route is currently in active state OPAQUE_REPL 0x08 Route is replicated from another VRF
OPAQUE_SRCWD 0x01ルートソースの撤回OPAQUE_CD 0x02候補のデフォルトルートOPAQUE_ACTIVE 0x04ルートは現在アクティブな状態ですOPAQUE_REPL 0x08ルートは別のVRFから複製されます
Extended Attributes (Optional): When present, defines extendable per-destination attributes. This field is not normally transmitted.
拡張属性（オプション）：存在する場合、宛先ごとの拡張可能な属性を定義します。このフィールドは通常送信されません。
Extended metrics allow for extensibility of the vector metrics in a manner similar to RFC 6390 [11]. Each Extended metric shall consist of a header identifying the type (Opcode) and the length (Offset) followed by application-specific information. Extended metric values not understood must be treated as opaque and passed along with the associated route.
拡張メトリックにより、RFC 6390 [11]と同様の方法でベクトルメトリックを拡張できます。各拡張メトリックは、タイプ（Opcode）と長さ（Offset）を識別するヘッダーと、その後に続くアプリケーション固有の情報で構成されます。理解できない拡張メトリック値は、不透明として扱われ、関連するルートとともに渡される必要があります。
The general formats for the Extended Metric fields are:
拡張メトリックフィールドの一般的な形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | Offset | Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opcode: Indicates the type of Extended Metric.
オペコード：拡張メトリックのタイプを示します。
Offset: Number of 16-bit words in the application-specific information. Offset does not include the length of the Opcode or Offset.
オフセット：アプリケーション固有の情報の16ビットワードの数。オフセットには、オペコードまたはオフセットの長さは含まれません。
Data: Zero or more octets of data as defined by Opcode.
データ：オペコードで定義されたゼロまたはそれ以上のデータのオクテット。
This is used to pad the attribute section to ensure 32-bit alignment of the metric encoding section.
これは、メトリックエンコーディングセクションの32ビットアラインメントを確保するために属性セクションを埋め込むために使用されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are:
フィールドは次のとおりです。
Opcode: Transmitted as zero (0).
オペコード：ゼロ（0）として送信されます。
Offset: Transmitted as zero (0) indicating no data is present.
オフセット：ゼロ（0）として送信され、データが存在しないことを示します。
Data: No data is present with this attribute.
データ：この属性を持つデータはありません。
If a route is received from a back-rev neighbor, and the route is selected as the best path, the scaled metric received in the older UPDATE may be attached to the packet. If received, the value is for informational purposes and is not affected by K6.
ルートがback-revネイバーから受信され、そのルートが最適パスとして選択されている場合、古いUPDATEで受信されたスケーリングされたメトリックがパケットに添付されることがあります。受け取った場合、値は情報提供を目的としており、K6の影響を受けません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x04 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scaled Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scaled Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: Transmitted as 0x0000
予約済み：0x0000として送信
Scaled Bandwidth: The minimum bandwidth along a path expressed in units of 2,560,000,000/kbps. A bandwidth of 0xFFFFFFFF indicates an unreachable route.
スケーリングされた帯域幅：2,560,000,000 / kbpsの単位で表されるパスに沿った最小帯域幅。帯域幅0xFFFFFFFFは、到達不能なルートを示します。
Scaled Delay: An administrative parameter assigned statically on a per-interface-type basis to represent the time it takes along an unloaded path. This is expressed in units of tens of microseconds divvied by 256. A delay of 0xFFFFFFFF indicates an unreachable route.
スケーリングされた遅延：アンロードされたパスにかかる時間を表すために、インターフェイスタイプごとに静的に割り当てられた管理パラメーター。これは、256で割った数十マイクロ秒の単位で表されます。0xFFFFFFFFの遅延は、到達できないルートを示します。
EIGRP administrative tag does not alter the path decision-making process. Routers can set a tag value on a route and use the flags to apply specific routing polices within their network.
EIGRP管理タグは、パスの意思決定プロセスを変更しません。ルーターはルートにタグ値を設定し、フラグを使用してネットワーク内に特定のルーティングポリシーを適用できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x02 | 0x02 | Administrator Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrator Tag (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Administrator Tag: A tag assigned by the network administrator that is untouched by EIGRP. This allows a network administrator to filter routes in other EIGRP border routers based on this value.
管理者タグ：EIGRPによって変更されない、ネットワーク管理者によって割り当てられたタグ。これにより、ネットワーク管理者は、この値に基づいて他のEIGRPボーダールーターのルートをフィルタリングできます。
EIGRP communities themselves do not alter the path decision-making process, communities can be used as flags in order to mark a set of routes. Upstream routers can then use these flags to apply specific routing polices within their network.
EIGRPコミュニティ自体はパスの意思決定プロセスを変更しないため、コミュニティを一連のルートをマークするためのフラグとして使用できます。アップストリームルータはこれらのフラグを使用して、ネットワーク内に特定のルーティングポリシーを適用できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x03 | Offset | Community List |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Offset: Number of 16-bit words in the sub-field.
オフセット：サブフィールドの16ビットワードの数。
Community List: One or more 8-octet EIGRP communities, as defined in Section 6.4.
コミュニティリスト：セクション6.4で定義されている1つ以上の8オクテットEIGRPコミュニティ。
(Optional) EIGRP can carry one-way Jitter in networks that carry UDP traffic if the node is capable of measuring UDP Jitter. The Jitter reported to will be averaged with any existing Jitter data and include in the route updates. If no Jitter value is reported by the peer for a given destination, EIGRP will use the locally collected value.
（オプション）ノードがUDPジッタを測定できる場合、EIGRPは、UDPトラフィックを伝送するネットワークで一方向ジッタを伝送できます。報告されたジッターは、既存のジッターデータと平均され、ルートの更新に含まれます。特定の宛先のピアからジッター値が報告されない場合、EIGRPはローカルに収集された値を使用します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x04 | 0x03 | Jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Jitter: The measure of the variability over time of the latency across a network measured in measured in microseconds.
ジッタ：マイクロ秒単位で測定された、ネットワーク全体のレイテンシの経時変化の測定値。
(Optional) EIGRP can carry energy usage by nodes in networks if the node is capable of measuring energy. The Quiescent Energy reported will be added to any existing energy data and include in the route updates. If no energy data is reported by the peer for a given destination, EIGRP will use the locally collected value.
（オプション）ノードがエネルギーを測定できる場合、EIGRPはネットワーク内のノードによるエネルギー使用量を運ぶことができます。報告された静止エネルギーは、既存のエネルギーデータに追加され、ルートの更新に含まれます。特定の宛先のピアからエネルギーデータが報告されない場合、EIGRPはローカルに収集された値を使用します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x05 | 0x02 | Q-Energy (high) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Q-Energy (low) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q-Energy: Paths with higher idle (standby) energy usage will be reflected in a higher aggregate metric than those having lower energy usage. If present, this number will represent the idle power consumption expressed in milliwatts per kilobit.
Q-Energy：アイドル（スタンバイ）エネルギー使用量が多いパスは、エネルギー使用量が少ないパスよりも高い集約メトリックに反映されます。存在する場合、この数値はキロビットあたりのミリワットで表されるアイドル電力消費を表します。
(Optional) EIGRP can carry energy usage by nodes in networks if the node is capable of measuring energy. The active Energy reported will be added to any existing energy data and include in the route updates. If no energy data is reported by the peer for a given destination, EIGRP will use the locally collected value.
（オプション）ノードがエネルギーを測定できる場合、EIGRPはネットワーク内のノードによるエネルギー使用量を運ぶことができます。報告されたアクティブなエネルギーは、既存のエネルギーデータに追加され、ルートの更新に含まれます。特定の宛先のピアからエネルギーデータが報告されない場合、EIGRPはローカルに収集された値を使用します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x06 | 0x02 | Energy (high) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Energy (low) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Energy: Paths with higher active energy usage will be reflected in a higher aggregate metric than those having lower energy usage. If present, this number will represent the power consumption expressed in milliwatts per kilobit.
エネルギー：アクティブなエネルギー使用量が多いパスは、エネルギー使用量が少ないパスよりも高い集約メトリックに反映されます。存在する場合、この数値はキロビットあたりのミリワットで表される電力消費を表します。
The Add Path enables EIGRP to advertise multiple best paths to adjacencies. There will be up to a maximum of four AddPaths supported, where the format of the field will be as follows.
パスの追加により、EIGRPは複数の最適パスを隣接にアドバタイズできます。最大4つのAddPathがサポートされ、フィールドの形式は次のようになります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x07 | Offset | AddPath (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Offset: Number of 16-bit words in the sub-field.
オフセット：サブフィールドの16ビットワードの数。
AddPath: Length of this field will vary in length based on whether it contains IPv4 or IPv6 data.
AddPath：このフィールドの長さは、IPv4またはIPv6データが含まれているかどうかによって異なります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x07 | Offset | Next-Hop Addr. (Upper 2 bytes)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (Lower 2 bytes) | RID (Upper 2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RID (Upper 2 bytes) | Admin Tag (Upper 2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Admin Tag (Upper 2 bytes) |Extern Protocol| Flags Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next-Hop Address: An IPv4 address represented by four 8-bit values (total 4 octets). If the value is zero (0), the IPv6 address from the received IPv4 header is used as the next hop for the route. Otherwise, the specified IPv4 address will be used.
ネクストホップアドレス：4つの8ビット値（合計4オクテット）で表されるIPv4アドレス。値がゼロ（0）の場合、受信したIPv4ヘッダーからのIPv6アドレスがルートのネクストホップとして使用されます。それ以外の場合は、指定されたIPv4アドレスが使用されます。
Router Identifier (RID): A 32-bit number provided by the router sourcing the information to uniquely identify it as the source.
ルーター識別子（RID）：ルーターが提供する32ビットの番号で、ソースとして一意に識別するための情報を提供します。
Admin Tag: A 32-bit administrative tag assigned by the network. This allows a network administrator to filter routes based on this value.
管理タグ：ネットワークによって割り当てられた32ビットの管理タグ。これにより、ネットワーク管理者はこの値に基づいてルートをフィルタリングできます。
If the route is of type external, then two additional bytes will be added as follows:
ルートのタイプが外部の場合、次のように2バイトが追加されます。
External Protocol: Contains an enumerated value defined in Section 6.2 to identify the routing protocol (external protocol) redistributing the route.
外部プロトコル：セクション6.2で定義された列挙値を含み、ルートを再配布するルーティングプロトコル（外部プロトコル）を識別します。
Flags Field: See Section 6.8.1.
フラグフィールド：セクション6.8.1を参照してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x07 | Offset | Next-Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| (16 octets) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | RID (Upper 2 byes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RID (Upper 2 byes) | Admin Tag (Upper 2 byes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Admin Tag (Upper 2 byes) | Extern Protocol | Flags Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Next-Hop Address: An IPv6 address represented by eight groups of 16-bit values (total 16 octets). If the value is zero (0), the IPv6 address from the received IPv6 header is used as the next hop for the route. Otherwise, the specified IPv6 address will be used.
ネクストホップアドレス：16ビット値の8つのグループ（合計16オクテット）で表されるIPv6アドレス。値がゼロ（0）の場合、受信したIPv6ヘッダーのIPv6アドレスがルートのネクストホップとして使用されます。それ以外の場合は、指定されたIPv6アドレスが使用されます。
Router Identifier (RID): A 32-bit number provided by the router sourcing the information to uniquely identify it as the source.
ルーター識別子（RID）：ルーターが提供する32ビットの番号で、ソースとして一意に識別するための情報を提供します。
Admin Tag: A 32-bit administrative tag assigned by the network. This allows a network administrator to filter routes based on this value. If the route is of type external, then two addition bytes will be added as follows:
管理タグ：ネットワークによって割り当てられた32ビットの管理タグ。これにより、ネットワーク管理者はこの値に基づいてルートをフィルタリングできます。ルートのタイプが外部の場合、2つの追加バイトが次のように追加されます。
External Protocol: Contains an enumerated value defined in Section 6.2 to identify the routing protocol (external protocol) redistributing the route.
外部プロトコル：セクション6.2で定義された列挙値を含み、ルートを再配布するルーティングプロトコル（外部プロトコル）を識別します。
Flags Field: See Section 6.8.1.
フラグフィールド：セクション6.8.1を参照してください。
Additional routing information provided for destinations outside of the EIGRP AS as follows:
EIGRP AS外の宛先に提供される追加のルーティング情報は、次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Identifier (RID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Autonomous System (AS) Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Protocol Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Extern Protocol| Flags Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router Identifier (RID): A 32-bit number provided by the router sourcing the information to uniquely identify it as the source.
ルーター識別子（RID）：ルーターが提供する32ビットの番号で、ソースとして一意に識別するための情報を提供します。
External Autonomous System (AS) Number: A 32-bit number indicating the external AS of which the sending router is a member. If the source protocol is EIGRP, this field will be the [VRID, AS] pair. If the external protocol does not have an AS, other information can be used (for example, Cisco uses process-id for OSPF).
外部自律システム（AS）番号：送信ルーターがメンバーになっている外部ASを示す32ビットの番号。ソースプロトコルがEIGRPの場合、このフィールドは[VRID、AS]ペアになります。外部プロトコルにASがない場合は、他の情報を使用できます（たとえば、シスコはOSPFにプロセスIDを使用します）。
External Protocol Metric: A 32-bit value of the metric used by the routing table as learned by the foreign protocol. If the External Protocol is IGRP or EIGRP, the value can (optionally) be 0, and the metric information is stored in the metric section.
外部プロトコルメトリック：外部プロトコルによって学習されたルーティングテーブルで使用されるメトリックの32ビット値。外部プロトコルがIGRPまたはEIGRPの場合、値は（オプションで）0にすることができ、メトリック情報はメトリックセクションに格納されます。
External Protocol: Contains an enumerated value defined in Section 6.2 to identify the routing protocol (external protocol) redistributing the route.
外部プロトコル：セクション6.2で定義された列挙値を含み、ルートを再配布するルーティングプロトコル（外部プロトコル）を識別します。
Flags Field: See Section 6.8.1.
フラグフィールド：セクション6.8.1を参照してください。
Destination information is encoded in Multiprotocol packets in the same manner used by Classic TLVs. This is accomplished by using a counter to indicate how many significant bits are present in the variable-length address field.
宛先情報は、クラシックTLVで使用されるのと同じ方法でマルチプロトコルパケットにエンコードされます。これは、可変長アドレスフィールドに存在する有効ビットの数を示すためにカウンターを使用することによって達成されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subnet Mask | Destination Address (variable length |
| Bit Count | ((Bit Count - 1) / 8) + 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Subnet Mask Bit Count: 8-bit value used to indicate the number of bits in the subnet mask. A value of 0 indicates the default network and no address is present.
サブネットマスクビット数：サブネットマスクのビット数を示すために使用される8ビット値。値0はデフォルトのネットワークを示し、アドレスは存在しません。
Destination Address: A variable-length field used to carry the destination address. The length is determined by the number of consecutive bits in the destination address. The formula to calculate the length is address-family dependent:
宛先アドレス：宛先アドレスを運ぶために使用される可変長フィールド。長さは、宛先アドレスの連続するビット数によって決まります。長さを計算する式はアドレスファミリによって異なります。
IPv4: ((Bit Count - 1) / 8) + 1
IPv6: (Bit Count == 128) ? 16 : ((x / 8) + 1)
This TLV conveys destination information based on the IANA AFI defined in the TLV Header (see Section 6.9.1), and associated metric information. Routes advertised in this TLV are network interfaces that EIGRP is configured on as well as networks that are learned via other routers running EIGRP.
このTLVは、TLVヘッダー（セクション6.9.1を参照）で定義されたIANA AFIと関連するメトリック情報に基づいて宛先情報を伝達します。このTLVでアドバタイズされるルートは、EIGRPが構成されているネットワークインターフェイスと、EIGRPを実行している他のルーターを介して学習されるネットワークです。
This TLV conveys destination information based on the IANA AFI defined in the TLV Header (see Section 6.9.1), and metric information for routes learned by other routing protocols that EIGRP injects into the AS. Available with this information is the identity of the routing protocol that created the route, the external metric, the AS number, an indicator if it should be marked as part of the EIGRP AS, and a network administrator tag used for route filtering at EIGRP AS boundaries.
このTLVは、TLVヘッダー（セクション6.9.1を参照）で定義されたIANA AFIに基づく宛先情報と、EIGRPがASに挿入する他のルーティングプロトコルによって学習されたルートのメトリック情報を伝達します。この情報で利用できるのは、ルートを作成したルーティングプロトコルのID、外部メトリック、AS番号、EIGRP ASの一部としてマークする必要があるかどうかのインジケーター、およびEIGRP ASでのルートフィルタリングに使用されるネットワーク管理者タグです。境界。
Being promiscuous, EIGRP will neighbor with any router that sends a valid HELLO packet. Due to security considerations, this "completely" open aspect requires policy capabilities to limit peering to valid routers.
EIGRPは無差別であるため、有効なHELLOパケットを送信するルーターと隣接します。セキュリティ上の理由から、この「完全に」オープンな側面には、ピアリングを有効なルーターに制限するポリシー機能が必要です。
EIGRP does not rely on a PKI or a heavyweight authentication system. These systems challenge the scalability of EIGRP, which was a primary design goal.
EIGRPは、PKIまたは重量のある認証システムに依存しません。これらのシステムは、主要な設計目標であったEIGRPのスケーラビリティに挑戦します。
Instead, Denial-of-Service (DoS) attack prevention will depend on implementations rate-limiting packets to the control plane as well as authentication of the neighbor through the use of MD5 or SHA2-256 [6].
代わりに、サービス拒否（DoS）攻撃の防止は、コントロールプレーンへのレート制限パケットの実装と、MD5またはSHA2-256を使用したネイバーの認証に依存します[6]。
This document serves as the sole reference for two multicast addresses: 224.0.0.10 for IPv4 "EIGRP Routers" [13] and FF02:0:0:0:0:0:0:A for IPv6 "EIGRP Routers" [14]. It also serves as assignment for protocol number 88 (EIGRP) [15].
このドキュメントは、IPv4「EIGRPルーター」[13]の224.0.0.10とIPv6「EIGRPルーター」[14]のFF02：0：0：0：0：0：0：Aの2つのマルチキャストアドレスの唯一のリファレンスとして機能します。プロトコル番号88（EIGRP）の割り当てとしても機能します[15]。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[2] Garcia-Luna-Aceves, J.J., "A Unified Approach to Loop-Free Routing Using Distance Vectors or Link States", SIGCOMM '89, Symposium proceedings on Communications architectures & protocols, Volume 19, pages 212-223, ACM 089791-332-9/89/0009/0212, DOI 10.1145/75247.75268, 1989.
[2] Garcia-Luna-Aceves、JJ、「距離ベクトルまたはリンク状態を使用したループフリールーティングへの統合アプローチ」、SIGCOMM '89、通信アーキテクチャとプロトコルに関するシンポジウム議事録、19巻、212-223ページ、ACM 089791-332- 9/89/0009/0212、DOI 10.1145 / 75247.75268、1989。
[3] Garcia-Luna-Aceves, J.J., "Loop-Free Routing using Diffusing Computations", Network Information Systems Center, SRI International, appeared in IEEE/ACM Transactions on Networking, Vol. 1, No. 1, DOI 10.1109/90.222913, 1993.
[3] Garcia-Luna-Aceves、J.J。、「拡散計算を使用したループフリールーティング」、ネットワーク情報システムセンター、SRI Internationalは、IEEE / ACM Transactions on Networking、Vol。 1、No。1、DOI 10.1109 / 90.222913、1993。
[4] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <http://www.rfc-editor.org/info/rfc7153>.
[4] ローゼン、E.、Y。レクター、「BGP拡張コミュニティのIANAレジストリ」、RFC 7153、DOI 10.17487 / RFC7153、2014年3月、<http://www.rfc-editor.org/info/rfc7153>。
[5] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <http://www.rfc-editor.org/info/rfc3692>.
[5] Narten、T。、「Assigning Testing and Testing Numbers考慮されたUseful」、BCP 82、RFC 3692、DOI 10.17487 / RFC3692、2004年1月、<http://www.rfc-editor.org/info/rfc3692>。
[6] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>.
[6] Kelly、S。およびS. Frankel、「IPsecでのHMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512の使用」、RFC 4868、DOI 10.17487 / RFC4868、2007年5月、<http：// www .rfc-editor.org / info / rfc4868>。
[7] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <http://www.rfc-editor.org/info/rfc1112>.
[7] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、DOI 10.17487 / RFC1112、1989年8月、<http://www.rfc-editor.org/info/rfc1112>。
[8] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[8] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<http://www.rfc-editor.org/info/rfc791>。
[9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[9] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/rfc2460>。
[10] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[10] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、DOI 10.17487 / RFC2328、1998年4月、<http://www.rfc-editor.org/info/rfc2328>。
[11] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <http://www.rfc-editor.org/info/rfc6390>.
[11] Clark、A.およびB. Claise、「新しいパフォーマンスメトリック開発を検討するためのガイドライン」、BCP 170、RFC 6390、DOI 10.17487 / RFC6390、2011年10月、<http://www.rfc-editor.org/info/rfc6390> 。
[12] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[12] IANA、「Address Family Numbers」、<http://www.iana.org/assignments/address-family-numbers>。
[13] IANA, "IPv4 Multicast Address Space Registry", <http://www.iana.org/assignments/multicast-addresses>.
[13] IANA、「IPv4 Multicast Address Space Registry」、<http://www.iana.org/assignments/multicast-addresses>。
[14] IANA, "IPv6 Multicast Address Space Registry", <http://www.iana.org/assignments/ipv6-multicast-addresses>.
[14] IANA、「IPv6 Multicast Address Space Registry」、<http://www.iana.org/assignments/ipv6-multicast-addresses>。
[15] IANA, "Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers>.
[15] IANA、「プロトコル番号」、<http://www.iana.org/assignments/protocol-numbers>。
Acknowledgments
謝辞
Thank you goes to Dino Farinacci, Bob Albrightson, and Dave Katz. Their significant accomplishments towards the design and development of the EIGRP provided the bases for this document.
Dino Farinacci、Bob Albrightson、Dave Katzの各氏に感謝します。 EIGRPの設計と開発に向けた彼らの重要な成果は、このドキュメントの基礎を提供しました。
A special and appreciative thank you goes to the core group of Cisco engineers whose dedication, long hours, and hard work led the evolution of EIGRP over the past decade. They are Donnie Savage, Mickel Ravizza, Heidi Ou, Dawn Li, Thuan Tran, Catherine Tran, Don Slice, Claude Cartee, Donald Sharp, Steven Moore, Richard Wellum, Ray Romney, Jim Mollmann, Dennis Wind, Chris Van Heuveln, Gerald Redwine, Glen Matthews, Michael Wiebe, and others.
特別で感謝の気持ちを込めて、献身的で長い時間とハードワークが過去10年間にEIGRPの進化を導いたシスコエンジニアのコアグループに感謝します。彼らは、ドニー・サベージ、ミケル・ラヴィザ、ハイジ・オー、ドーン・リー、トゥアン・トラン、キャサリン・トラン、ドン・スライス、クロード・カルティー、ドナルド・シャープ、スティーブン・ムーア、リチャード・ウェルム、レイ・ロムニー、ジム・モルマン、デニス・ウィンド、クリス・ヴァン・ヒューヴェルン、ジェラルド・レッドワイン、Glen Matthews、Michael Wiebe、その他。
The authors would like to gratefully acknowledge many people who have contributed to the discussions that lead to the making of this proposal. They include Chris Le, Saul Adler, Scott Van de Houten, Lalit Kumar, Yi Yang, Kumar Reddy, David Lapier, Scott Kirby, David Prall, Jason Frazier, Eric Voit, Dana Blair, Jim Guichard, and Alvaro Retana.
著者は、この提案の作成につながった議論に貢献してくれた多くの人々に感謝したいと思います。クリスル、ソールアドラー、スコットヴァンデフーテン、ラリットクマール、イーヤン、クマーレディ、デビッドレイピア、スコットカービー、デビッドプラール、ジェイソンフレイザー、エリックヴォイト、ダナブレア、ジムギチャード、アルバロレタナが含まれます。
In addition to the tireless work provided by the Cisco engineers over the years, we would like to personally recognize the teams that created open source versions of EIGRP:
長年にわたってシスコのエンジニアによって提供された精力的な作業に加えて、EIGRPのオープンソースバージョンを作成したチームを個人的に認識したいと思います。
o Linux implementation developed by the Quagga team: Jan Janovic, Matej Perina, Peter Orsag, and Peter Paluch.
o Quaggaチームが開発したLinux実装：Jan Janovic、Matej Perina、Peter Orsag、およびPeter Paluch。
o BSD implementation developed and released by Renato Westphal.
o Renato Westphalが開発およびリリースしたBSD実装。
Authors' Addresses
著者のアドレス
Donnie V. Savage Cisco Systems, Inc. 7025 Kit Creek Rd., RTP, Morrisville, NC 27560 United States Phone: 919-392-2379 Email: dsavage@cisco.com
Donnie V. Savage Cisco Systems、Inc. 7025 Kit Creek Rd。、RTP、Morrisville、NC 27560 United States電話：919-392-2379メール：dsavage@cisco.com
James Ng Cisco Systems, Inc. 7025 Kit Creek Rd., RTP, Morrisville, NC 27560 United States Phone: 919-392-2582 Email: jamng@cisco.com
James Ng Cisco Systems、Inc. 7025 Kit Creek Rd。、RTP、Morrisville、NC 27560 United States電話：919-392-2582メール：jamng@cisco.com
Steven Moore Cisco Systems, Inc. 7025 Kit Creek Rd., RTP, Morrisville, NC 27560 United States Phone: 408-895-2031 Email: smoore@cisco.com
Steven Moore Cisco Systems、Inc. 7025 Kit Creek Rd。、RTP、Morrisville、NC 27560 United States電話：408-895-2031メール：smoore@cisco.com
Donald Slice Cumulus Networks Apex, NC United States Email: dslice@cumulusnetworks.com
Donald Slice Cumulus Networks Apex、NCアメリカ合衆国メール：dslice@cumulusnetworks.com
Peter Paluch University of Zilina Univerzitna 8215/1, Zilina 01026 Slovakia Phone: 421-905-164432 Email: Peter.Paluch@fri.uniza.sk
ピーターパルチジリナ大学Univerzitna 8215/1、ジリーナ01026スロバキア電話：421-905-164432メール：Peter.Paluch@fri.uniza.sk
Russ White LinkedIn Apex, NC United States Phone: 1-877-308-0993 Email: russw@riw.us
Russ White LinkedIn Apex、NC United States電話：1-877-308-0993メール：russw@riw.us