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
        
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)

Cisco的增强型内部网关路由协议(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.

本文档描述了增强型内部网关路由协议(EIGRP)的协议设计和体系结构。EIGRP是一种基于距离向量技术的路由协议。使用的特定算法称为“DUAL”,这是一种扩散更新算法,如“使用扩散计算的无环路由”(Garcia Luna Aceves 1993)中所述。该算法和程序由SRI国际研究、开发和模拟。

Status of This Memo

关于下段备忘

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文件不是互联网标准跟踪规范;它是为了提供信息而发布的。

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编辑批准发布的文件不适用于任何级别的互联网标准;见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.

版权所有(c)2016 IETF信托基金和确定为文件作者的人员。版权所有。

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
        
   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
        
      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
        
           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
        
1. Introduction
1. 介绍

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.

本文件描述了增强型内部网关路由协议(EIGRP),这是一种由Cisco Systems,Inc.设计和开发的路由协议。DUAL,用于将控制平面聚合到单个无环路路径集的算法基于SRI International进行的研究[3]。扩散更新算法(DUAL)是用于在路由计算过程中的每一时刻获得环路自由度的算法[2]。这允许拓扑更改中涉及的所有路由器同时同步;不受拓扑更改影响的路由器不参与重新计算。本文档描述了实现这些功能的协议。

2. Conventions
2. 习俗
2.1. Requirements Language
2.1. 需求语言

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].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。

2.2. Terminology
2.2. 术语

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):正在公布的网络层协议可达性信息的标识[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.

自治系统(AS):在一个或多个网络管理员代表单个管理实体控制下交换路由的路由器集合。

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)标识。

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)和两个路由器之间的链路成本计算。每个[目的地,广告邻居]对只计算和维护一张CD。

CR-Mode Conditionally Received 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国际公司研发[3]。

Downstream Router: A router that is one or more hops away from the router in question in the direction of the destination.

下游路由器:在目的地方向上,距离相关路由器一个或多个跃点的路由器。

EIGRP: Enhanced Interior Gateway Routing Protocol.

EIGRP:增强的内部网关路由协议。

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.

可行距离(FD):定义为自上次从主动状态过渡到被动状态以来,从当前路由器到目的地的最小已知总度量。作为自上次网络进入被动状态以来的最小已知度量的有效记录,FD不一定是当前最佳路径的度量。每个目标网络只计算一个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会话(也称为“邻接”)的路由器。两个路由器成为邻居的能力取决于它们的相互连通性和所选EIGRP配置参数的兼容性。具有连接到公共子网的接口的两个邻居称为相邻邻居。两个相隔多跳的邻居称为远程邻居。

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.

被动状态:路由的本地状态,其中至少有一个提供当前最低成本路径的邻居通过可行性条件检查。处于被动状态的路由被认为是可用的,不需要协调的重新计算。

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不等于路由器到目的地的当前距离,并且在路径重新计算过程中可能与之不同。每个目标网络只计算和维护一个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).

卡在活动状态(SIA):在本地路由器上保持活动状态超过预定义时间段的目的地(Cisco将其实现为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):对于特定目的地,由拓扑中各个路由器的路由表内容定义的图,该图的节点是路由器本身,当且仅当路由器Y是路由器X的后继路由器时,存在从路由器X到路由器Y的有向边。网络收敛后,在没有拓扑变化的情况下,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的任何事件。例如,检测链路成本变化,从邻居接收任何EIGRP消息,宣传更新的邻居的RD。

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格式的信息元素由三个通用字段组成:标识该元素中携带的信息性质的类型、描述整个TLV三元组长度的长度以及携带实际信息的值。值字段本身可以是内部结构;这取决于信息元素的实际类型。此格式允许扩展性和向后兼容性。

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.

上游路由器:在信息源的方向上,距离相关路由器一个或多个跃点的路由器。

VID: VLAN Identifier

VID:VLAN标识符

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)路由/转发表。

3. The Diffusing Update Algorithm (DUAL)
3. 扩散更新算法(对偶)

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)构造到由节点和边缘(路由器和链路)组成的网络中所有可到达目的地的最小代价路径。双重保证每个构建的路径在任何时刻都是无环的,包括拓扑变化和网络重新聚合的周期。这是由受拓扑变化影响的所有路由器完成的,以协调(扩散)方式计算新的最佳路径,并使用可行性条件验证环路自由的预期路径。不受拓扑更改影响的路由器不参与重新计算。与现有路由协议的双竞争对手的收敛时间。

3.1. Algorithm Description
3.1. 算法描述

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.

分布式路由算法需要在网络中的所有节点之间传播信息和协调信息。与基本Bellman-Ford距离向量协议不同,基本Bellman-Ford距离向量协议在拓扑发生变化时依赖于不协调的更新,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的一个属性是它通过管理网络中可达性信息的分布来控制路由计算扩散终止点的能力。

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中创建有效故障域的能力,并允许网络管理员管理网络的聚合和处理特性。

3.2. Route States
3.2. 路由状态

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.

到目的地的路由可以处于两种状态之一:被动或主动。这些状态描述路由是否保证无环路和可用最短路径(被动状态),或者是否不能提供这种保证(主动状态)。因此,在被动状态下,路由器不与邻居协调执行任何路由重新计算,因为不需要这样的重新计算。

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.

在活动状态下,路由器与邻居协调,积极参与重新计算最小成本无环路路径。每次检测到拓扑更改时,都会重新评估状态,并且可能会更改状态。拓扑更改是指导致通过任何邻居将CD添加到目标的任何事件,或导致从EIGRP的拓扑表中添加、更改或删除该事件。

More exactly, the two states are defined as follows:

更准确地说,这两种状态的定义如下:

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.

当提供当前最小总成本路径的至少一个邻居通过保证环路自由的可行性条件检查时,认为路由处于被动状态。处于被动状态的路由是可用的,其下一跳被认为是下游路由器。

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.

如果未通过可行性条件检查的邻居提供成本最低的路径,则认为路由处于活动状态,因此无法保证该路径无环路。处于活动状态的路由被视为不可用,此路由器必须与其邻居协调,以搜索新的无环路最小总成本路径。

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.

换句话说,对于处于被动状态的路由,至少一个提供最小总成本路径的邻居必须是可行的后继路径。提供最小总成本路径的可行继任者也称为“继任者”。要使路由处于被动状态,必须至少存在一个后续路由。

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。在活动状态期间收到的有关此路由的任何更新信息仅反映在CD中。对后继、FD和RD的任何更新都将延迟,直到路由返回被动状态。从被动到主动以及从主动到被动的状态转换由双FSM控制,详见第3.5节。

3.3. Feasibility Condition
3.3. 可行性条件

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).

可行性条件用作对偶操作的一个组成部分:对偶中的每个路径选择都要接受可行性条件检查。根据检测到拓扑变化后可行性条件检查的结果,路由可以保持被动(如果拓扑变化后,提供最小成本路径的邻居满足可行性条件),或者需要进入主动状态(如果拓扑更改导致没有任何邻居提供成本最低的路径以满足可行性条件)。

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.

首先,如果被告知拓扑变化,路由器可能会将路由保持在被动状态,前提是它知道其他路径在下游朝向目的地(满足可行性条件的路由)。满足可行性条件的路由被确定为无环路且沿着路由器和目的地之间的路径下行。

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.

其次,如果被告知当前没有可达性信息的拓扑更改,则路由器不需要进入活动状态,也不需要参与双重过程。

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.

以不满足可行性条件的代价宣传路由的邻居可能是上游的,因此不能保证是无环路路径的下一跳。上游邻居播发的路由不会记录在路由表中,而是保存在拓扑表中。

3.4. DUAL Message Types
3.4. 双重消息类型

DUAL operates with three basic message types: QUERY, UPDATE, and REPLY.

DUAL使用三种基本消息类型进行操作:查询、更新和回复。

o UPDATE - sent to indicate a change in metric or an addition of a destination.

o 更新-发送以指示指标的更改或目的地的添加。

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 查询-在可行性条件失败时发送,原因可能是目标变得不可访问或度量增加到大于其当前FD的值。

o REPLY - sent in response to a QUERY or SIA-QUERY

o 答复-为响应查询或SIA-QUERY而发送

In addition to these three basic types, two additional sub-types have been added to EIGRP:

除了这三种基本类型外,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秒)未收到回复时发送。

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.

当处于被动状态时,如果没有找到可行的后续查询,则可以传播接收到的查询。如果找到了可行的后继者,则不会传播查询,并使用等于当前路由表度量的度量向目标发送回复。当从处于活动状态的非后续查询接收到查询时,将发送回复,并且不会传播该查询。目标的应答包含一个等于当前路由表度量的度量。

3.5. DUAL Finite State Machine (FSM)
3.5. 双有限状态机(FSM)

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.

双重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)
        
              +------------+                +-----------+
              |             \              /            |
              |              \            /             |
              |   +=================================+   |
              |   |                                 |   |
              |(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:双有限状态机

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

正在计算路由j目的地节点或网络k的i节点i oij查询起始标志0=活动状态期间的度量增加1=节点i起源2=查询来源或链接增加至,活动状态期间的后继程序3=源于后继程序rijk的查询目的地j的每个邻居k的应答状态标志1=等待应答0=接收到的应答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.

以下详细描述了双FSM的状态/事件/动作转换。对于所有步骤,拓扑表都会使用来自查询、回复或更新接收的新度量信息进行更新。

(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) 从不是当前后继者的邻居接收查询。路由当前处于被动状态。由于后续路由不受查询的影响,并且存在可行的后续路由,因此路由仍处于被动状态。由于存在可行的后继者,因此必须将答复发送回查询的发起人。在查询中从该邻居接收到的任何度量都记录在拓扑表中,并运行可行性检查(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) 直接连接的接口更改状态(连接、断开连接或更改度量),或者类似地,已收到对现有目的地进行度量更改的更新或查询,如果当前后续接口不受更改影响,则路由将保持被动状态,或者它已经不可能实现,并且有一个可行的继任者。在这两种情况下,如果新的度量信息已更改,则会发送一个更新。

(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) 从作为当前继任者的邻居接收到查询,但不存在可行的继任者。目的地的路由进入活动状态。查询将发送到所有未拆分的接口上的所有邻居。“拆分地平线”对查询中用于目标的后续查询或更新生效。查询源标志设置为指示查询源于标记为路由后续的邻居。已为所有邻居设置回复状态标志,以指示未完成的回复。

(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) 直接连接的链路已下降或其成本已增加,或已接收到更新,但指标有所增加。如果没有找到可行的后继者,则到目的地的路由将进入活动状态。查询被发送到所有接口上的所有邻居。queryorigin标志表示路由器发起了查询。所有邻居的回复状态标志都设置为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) 当目的地的路由处于活动状态,并且从当前后续路由接收到查询时,路由仍处于活动状态。“查询原点”标志设置为指示处于活动状态时发生了另一个拓扑更改。使用此指示,以便将新的可行后继路由与使路由与当前后继路由进入活动状态的度量进行比较。

(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) 当目的地的路由处于活动状态且从不是当前后继路由的邻居接收到查询时,应向该邻居发送回复。应记录查询中收到的度量。

(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) 如果链路成本发生变化,或者在活动状态下从非后继路由器接收到具有度量变化的更新,则路由器将保持目的地的活动状态。将记录更新中的度量信息。当路由处于活动状态时,不会发送查询或更新。

(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) 如果从邻居处接收到处于活动状态的目的地的应答,或者路由器与邻居之间的链路出现故障,路由器将记录邻居对查询的应答。应答状态标志设置为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) 如果目的地的路由处于活动状态,并且路由器与其后继路由器之间的链路出现故障或成本增加,则路由器将此情况视为已收到后继路由器的回复。当路由器发起查询后发生这种情况时,它会设置查询起始标志,以指示在活动状态下发生了另一个拓扑更改。

(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) 如果目的地的路由处于活动状态,并且路由器与其后继路由器之间的链路出现故障或成本增加,则路由器将此情况视为已收到后继路由器的回复。当后继程序发起查询后发生这种情况时,路由器将设置查询起始标志,以指示在活动状态下发生了另一个拓扑更改。

(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) 如果一个目的地的路由处于活动状态,则后继者通过的链路的成本增加,并且从所有邻居处收到了最后的回复,但没有可行的后继者,则该路由应保持活动状态。将向所有邻居发送查询。查询原点标志设置为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) 如果由于从当前后继者接收到查询,目的地的路由处于活动状态,并且从所有邻居接收到最后一个答复,但没有可行的后继者,则路由应保持活动状态。将向所有邻居发送查询。查询原点标志设置为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) 收到所有邻居的回复。由于queryorigin标志指示发起查询的后继者,因此它将转换为被动状态并向旧后继者发送应答。

(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) 收到所有邻居的回复。由于queryorigin标志指示处于活动状态时对后继对象的拓扑更改,因此它不需要向旧后继对象发送回复。当满足可行性条件时,路由状态转换为被动。

(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 origin标志表示发起查询的路由器本身或FC对在活动状态下接收到的应答不满意,因此FD重置为无穷大值,并将所有报告的度量中的最小值选择为FD,并将路由转换回被动状态。如果oij标志指示有来自继任者的查询,则会向旧继任者发送回复。

(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) 如果目的地的路由由于从当前后继者收到的查询而处于活动状态,或者在活动状态下距离增加,则从所有邻居处收到最后一个答复,并且目的地存在可行的后继者,如果oij指示从后继路由接收到查询,则路由可以进入被动状态,并向后继路由发送回复。

3.6. DUAL Operation -- Example Topology
3.6. 双操作——拓扑示例

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)
        
                                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                                   N
          |                                   |
          A ---<--- B                         A ---<--- B
          |         |                         |          |
          X         |                         ^          |
          |         |                         |          |
          D ---<--- C                         D ---<--- C
            Q->                                      <-R
        
                             N
                             |
                          (1)A ---<--- B(2)
                                       |
                                       ^
                                       |
                          (4)D --->--- C(3)
        
                             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将其旧的继承者D更改为新的单一继承者B,并且到N的路由保持被动状态。D接收到回复,并且可以转换出活动状态,因为它接收到来自其所有邻居的回复。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从它的表中删除(现在不可到达)目的地时,C将应答发送给它的旧继承者。B从C接收该回复,并确定这是在确定路由的新状态之前它等待的最后一个回复;在收到此回复后,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是初始查询的发起者,因此它不必向其旧的继承者发送回复(它将无法以任何方式发送回复,因为与旧继承者的链接已断开)。请注意,节点A和D不参与重新计算,因为它们的后续节点不受影响。

          N                                N
          |                                |
       (1)A ---<--- B(2)                   A ------- B   Q
          |         |                      |         |   |^      ^
          ^         ^                      ^         |   v|      |
          |         |                      |         |      |    |
       (2)D         C(3)                   D         C     ACK   R
        
          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之间的链路出现故障时,没有可行的后继者

4. EIGRP Packets
4. EIGRP数据包

EIGRP uses five different packet types to handle session management and pass DUAL Message types:

EIGRP使用五种不同的数据包类型来处理会话管理和传递双重消息类型:

HELLO Packets (includes ACK) QUERY Packets (includes SIA-Query) REPLY Packets (includes SIA-Reply) REQUEST Packets UPDATE Packets

HELLO数据包(包括ACK)查询数据包(包括SIA查询)回复数据包(包括SIA回复)请求数据包更新数据包

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]
        
      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.

它们将在支持多播的媒体上使用,并且对于单播地址是独立于媒体的。将使用网络层地址,并通过本机协议机制实现到媒体地址的映射。

4.1. UPDATE Packets
4.1. 更新数据包

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.

更新包携带双重更新消息类型,用于传递有关目的地和这些目的地的可达性的信息。当发现一个新邻居时,使用单播更新包向新邻居发送一个完整的表,以便邻居可以建立其拓扑表。在正常操作中(除了邻居启动,如链路成本变化),更新数据包是多播的。更新数据包总是可靠地传输。每个TLV目的地将通过双FSM单独处理。

4.2. QUERY Packets
4.2. 查询包

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.

查询数据包携带双查询消息类型,由路由器发送,以通知路由处于活动状态,并且发起者正在向其邻居请求备用路径信息。通过将度量的延迟部分设置为其最大值,对无限度量进行编码。

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将为所有存在的目的地构建一个或多个查询数据包。每个路由的状态都是单独记录的,因此响应查询或应答不需要在单个数据包中包含所有相同的目的地。由于EIGRP使用可靠的传输机制,因此路由查询数据包也保证可靠地传递。

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.

当接收到查询数据包时,每个目的地将触发一个双重事件,并且状态机将针对每个路由单独运行。处理完整个原始查询数据包后,将发送带有最新信息的回复或SIA-REPLY。

4.3. REPLY Packets
4.3. 回复包

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.

应答包携带双重应答消息类型,并将被发送以响应查询或SIA-QUERY包。应答包将包括每个目的地的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.

在处理整个接收到的查询数据包之后发送应答数据包。当收到回复数据包时,没有理由在发送确认之前处理该数据包。因此,立即发送确认,然后处理数据包。确认的发送可以通过发送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目的地将通过双FSM单独处理。当接收到拓扑表中不存在的路由的查询时,将发送一个具有无限度量的回复,如果度量不是无限值,则拓扑表中的一个条目将与查询中的度量一起添加。

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.

如果指定的应答不处于活动状态,或不在拓扑表中,EIGRP将确认数据包并放弃应答。

4.4. Exception Handling
4.4. 异常处理
4.4.1. Active Duration (SIA)
4.4.1. 有效持续时间(SIA)

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路由器转换到特定目的地的活动状态时,将向邻居发送查询,并启动活动计时器以限制目的地可能保持活动状态的时间量。

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.

当一条路由在预设时间内未收到回复时,该路由被视为SIA。该时间间隔在查询后分为两个相等的时段,以及最多三个额外的“繁忙”时段,在这三个时段中,SIA-QUERY数据包被发送到目的地。

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

当路由器向其邻居发送查询时,此过程开始。在SIA时间间隔的一半(默认实现为90秒)后,路由器将发送SIA-QUERY;必须以回复或SIA-REPLY的形式对此进行回复。任何未能发送消息的邻居

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间隔内的应答或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.

Cisco还将SIA-REPLY消息的数量限制为三条。一旦在第三次SIA-REPLY之后发生超时,且邻居仍处于活动状态(如SIA回复消息中所述),则认为邻居“卡在”活动状态。

If the SIA state is declared, DUAL may take one of two actions;

如果宣布SIA状态,DUAL可采取两种行动之一;

a) Delete the route from that neighbor, acting as if the neighbor had responded with an unreachable REPLY message from the neighbor.

a) 删除来自该邻居的路由,就像该邻居使用来自该邻居的无法访问的回复消息进行响应一样。

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).

实施说明:Cisco目前实施选项(b)。

4.4.1.1. SIA-QUERY
4.4.1.1. SIA-QUERY

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.

当查询仍然未完成并等待邻居的答复时,没有足够的信息来确定未收到答复的原因。丢失的数据包、链路上的拥塞或速度较慢的邻居都可能导致下游邻居没有回复。

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,发起路由器可以通过重置先前设置的活动计时器来延长有效活动时间,从而允许聚合继续,只要邻居设备成功通信该聚合仍在进行中。

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数据包应按每个目的地发送,发送时间为活动超时时间的一半。对于一个特定目的地,最多可以发送三个SIA-QUERY数据包,每个数据包的有效时间值为活动时间的一半,只要每个数据包都被成功确认并得到SIA-REPLY。

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响应发端人,表明该目的地的活动处理仍在进行中。

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,该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来自继任者,当且仅当可行性条件检查失败时,才转换为活动状态,并发送带有活动位集的SIA-REPLY

4.4.1.2. SIA-REPLY
4.4.1.2. 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数据包将与活动位一起发送。这为邻居设备确认SIA-QUERY数据包已由DUAL处理,并且路由器仍在尝试解析无环路路径(可能正在等待对下游邻居的自身查询的响应)。

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的设备确定是否应继续允许未聚合的路由处于活动状态,或者是否应重置邻居关系并通过该邻居刷新所有路由。

5. EIGRP Operation
5. EIGRP操作

EIGRP has four basic components:

EIGRP有四个基本组件:

o Finite State Machine o Reliable Transport Protocol o Neighbor Discovery/Recovery o Route Management

o 有限状态机o可靠传输协议o邻居发现/恢复o路由管理

5.1. Finite State Machine
5.1. 有限状态机

The detail of DUAL, the State Machine used by EIGRP, is covered in Section 3.5.

第3.5节介绍了EIGRP使用的状态机DUAL的详细信息。

5.2. Reliable Transport Protocol
5.2. 可靠传输协议

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,其中包中有一个指示,通知接收者不需要确认包。其他类型的数据包(如更新数据包)需要确认,这在数据包中有所指示。可靠传输有一个规定,当有未确认的数据包挂起时,可以快速发送多播数据包。这有助于确保在存在变速链路的情况下保持较低的收敛时间。

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.

当路由器发送数据包时,它增加其序列号,并将数据包标记为需要发送数据包的接口上的所有邻居确认。当单个确认由接收方单播发送给发送方,且确认号等于数据包序列号时,发送方应从相应的邻居处清除数据包的待定确认要求。

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.

重复的数据包在收到时也会被丢弃。确认不是累积的。因此,具有非零序号的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数据包中的序列类型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说明了点到点链路上的可靠传输协议。可能出现两种情况:更新启动的数据包交换或查询启动的数据包交换。

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 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
        
                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
        
---------------->
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.

更新交换序列要求发送的更新数据包能够可靠地传递。发送的更新分组包含通过接收ACK分组而确认的序列号。如果更新或ACK数据包在网络上丢失,更新数据包将被重新传输。

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
        
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
        
                                 <--/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
        
                                 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显示了以太网上有四个路由器的示例。

           Router B -----------+
                               |
           Router C -----------+------------ Router A
                               |
           Router D -----------+
        
           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
        
                        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
        
---------------->
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
        
---------------->
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
        
                         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
        
---------------->
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
        
---------------->
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 -----------+
        
        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
        
                                <----------------
                                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
        
---------------->
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
        
---------------->
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
        
                                <----------------
                                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忽略更新101,因为设置了CR标志并且它不处于CR模式

---------------->
C sends ACK (unicast)
SEQ=0, ACK=101
        
---------------->
C sends ACK (unicast)
SEQ=0, ACK=101
        
---------------->
D sends ACK (unicast)
        
---------------->
D sends ACK (unicast)
        
SEQ=0, ACK=101
                                <----------------
                                A resends UPDATE (unicast to B)
                                SEQ=100, ACK=0
B packet duplicate
        
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=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
        
--------------->
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在LAN上发送一个多播寻址的更新包。B和C接收并发送确认。路由器B接收更新,但发送的确认在网络上丢失。在路由器B的数据包的重传计时器到期之前,有一个事件导致发送新的多播寻址更新。

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检测到接口上至少有一个邻居队列已满。因此,它必须向邻居发出不接收下一个数据包的信号,否则它将按顺序接收重新传输的数据包。如果接口上的所有邻居都有一个满队列,那么一旦队列不再满,EIGRP应该重新安排更新的传输。

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构建一个HELLO数据包,其序列类型为TLV,表示所有队列已满的邻居。在这种情况下,列表中唯一的邻居地址是路由器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通过在列表中查找自己的地址来处理序列_类型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在序列TLV对等列表中找不到其地址,因此它进入CR模式。路由器B接收到的带有CR标志的数据包必须被丢弃且不被确认。

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的传输列表中删除这两个数据包。

5.2.1. Bandwidth on Low-Speed Links
5.2.1. 低速链路上的带宽

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的接口定义了一个接口调整计时器。当起搏计时器过期时,数据包将在该接口上传输出去。

5.3. Neighbor Discovery/Recovery
5.3. 邻居发现/恢复

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数据包以低开销实现。只要从邻居接收到任何数据包,路由器就可以确定邻居是否处于活动状态并正常工作。只有在邻居路由器被认为是可操作的之后,邻居路由器才能交换路由信息。

5.3.1. Neighbor Hold Time
5.3.1. 邻居等待时间

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数据包之外,如果在保持时间段内收到任何数据包,则保持时间段将被重置。当保持时间到期时,DUAL将收到拓扑更改的通知。

5.3.2. HELLO Packets
5.3.2. 你好,小包

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值相同时,两个路由器才会成为邻居。这强制要求度量使用在整个互联网上保持一致。HELLO数据包中还包括保持时间值。该值向所有接收器指示邻居有效的时间长度(秒)。默认保持时间将是HELLO间隔的三倍。HELLO数据包将每5秒传输一次(默认情况下)。可能有一个配置命令控制该值,从而更改保持时间。HELLO数据包传输不可靠,因此序列号应设置为0。

5.3.3. UPDATE Packets
5.3.3. 更新数据包

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数据包来检测新邻居。为了确保单播和多播数据包的传递,检测邻居将向新邻居发送一个单播更新数据包,而没有路由信息(空更新数据包)。发送的初始NULL更新数据包必须设置INIT标志并且不包含拓扑信息。

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.

实施说明:空更新数据包用于确保双向单播数据包交付,因为空更新和ACK都是单播发送的。在确认初始空更新数据包之前,无法发送其他更新数据包。

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标志指示邻居公布其路由,当邻居宕机并在路由器检测到它宕机之前返回时,它也很有用。在这种情况下,邻居需要新的路由信息。INIT标志通知路由器发送它。

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标志的更新,并且在报头中没有设置Restart(RS)标志时,接收邻居也必须发送一个设置了INIT标志的更新。否则将导致Cisco设备出现“卡在初始状态”错误并随后丢弃。

5.3.4. Initialization Sequence
5.3.4. 初始化序列

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
        
        (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
        
                                         <----------------     (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标志的空更新包。第二个数据包已排队,但在确认第一个数据包之前无法发送。

(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接收第一个更新包并将其作为双事件处理。如果更新包含拓扑信息,则数据包将被处理并存储在拓扑表中。路由器B发送其第一个也是唯一一个带有伴随ACK的更新包。

(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接收更新包100。自更新确认10以来,路由器B可以将包10从A的传输列表中排出。它现在可以发送更新包11,并确认路由器A的更新。

(5) Router A receives the last UPDATE packet from Router B and acknowledges it. The acknowledgment gets lost.

(5) 路由器A从路由器B接收最后一个更新包并确认它。确认信息丢失了。

(6) Router B later retransmits the UPDATE packet to Router A.

(6) 路由器B随后将更新包重新传输到路由器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从A的传输列表中取出数据包11,两个路由器都启动并同步。

5.3.5. Neighbor Formation
5.3.5. 相邻编队

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.

为了在验证多播和单播数据包传递是否可靠之前防止数据包被发送到邻居,使用了三向握手。

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向无法进行双向单播/多播的邻居发送序列数据包,或者在建立关系时一个邻居重新启动,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置于挂起状态,并发送不包含拓扑信息的单播更新,并应设置初始化位。当路由器B处于这种状态时,A将不向其发送查询或更新。当路由器A从路由器B接收到单播确认时,它将把状态从“挂起”更改为“向上”。

5.3.6. QUERY Packets during Neighbor Formation
5.3.6. 邻居形成期间的查询数据包

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使用三方握手的形式来验证单播和多播连接是否都成功工作。在创建邻居的这段时间内,新邻居被视为处于挂起状态,并且它没有资格被包括在收敛过程中。

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路由器接收到的任何查询都不会导致将查询发送到新的(挂起的)邻居。它将在对话中没有新的对等方的情况下执行双重过程。为此,当路由器在建立新邻居的过程中收到来自完全建立的邻居的查询时,它将执行正常的双可行后继检查,以确定是否需要使用有效路径进行应答,或者是否需要在前缀上输入活动进程。

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.

如果它确定它必须处于活动状态,则参与聚合过程的每个完全建立的邻居都将被发送一个查询数据包,并且每个邻居都将收到回复数据包。任何挂起的邻居都不会回复,也不会直接发送查询。如果它驻留在一个包含完全建立的邻居和挂起的邻居的混合接口上,它可能会接收查询,但它不会回复查询。

5.4. Topology Table
5.4. 拓扑表

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)填充,并由双有限状态机对其进行操作。与每个条目关联的是目标地址、播发此目标的邻居列表以及与目标关联的度量。该指标称为“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”是目的地的可行继任者所宣传的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.

如果路由器正在公布目的地路由,它必须使用该路由转发数据包;这是距离向量协议必须遵循的一条重要规则。

5.4.1. Route Management
5.4.1. 路线管理

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才会从可用的外部路由中选择后续路由。

5.4.1.1. Internal Routes
5.4.1.1. 内部路线

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的目的地。因此,配置为运行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可配置的管理员标签。

5.4.1.2. External Routes
5.4.1.2. 外路

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:

外部路由是从另一个源(如不同的路由协议或静态路由)学习的目的地。这些路线分别标有其来源的标识。外部路线标记有以下信息:

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作为目的地所在的编号。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).

例如,假设有一个As和三个边界路由器:BR1、BR2和BR3。边界路由器是运行多个路由协议的路由器。AS使用EIGRP作为路由协议。边界路由器中的两个,BR1和BR2,也使用开放最短路径优先(OSPF)[10],另一个,BR3,也使用路由信息协议(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边界路由器之一BR1学习的路由可以有条件地重新分配到EIGRP中。这意味着在BR1中运行的EIGRP在其自身的AS中公布OSPF路由。当它这样做时,它播发该路由并将其标记为OSPF学习路由,其度量等于OSPF路由的路由表度量。路由器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.

假设BR3,RIP边界路由器,也宣传与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通常与实现全局策略的域间路由协议交互的传输ASE中特别有用。

5.4.2. Split Horizon and Poison Reverse
5.4.2. 分裂地平线和毒药逆转

In some circumstances, EIGRP will suppress or poison QUERY and UPDATE information to prevent routing loops as changes propagate though the network.

在某些情况下,EIGRP将抑制或毒害查询和更新信息,以防止在更改通过网络传播时出现路由循环。

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".

在Cisco内部,拆分地平线规则建议:“永远不要宣传一条从接口传出的路由,通过该接口可以了解到该路由”。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中,split horizon会抑制查询,其中as poison reverse会将目标播发为无法访问。在以下任何情况下,目的地都可能发生这种情况:

o two routers are in startup or restart mode o advertising a topology table change o sending a query

o 两个路由器处于启动或重启模式o公布拓扑表更改o发送查询

5.4.2.1. Startup Mode
5.4.2.1. 启动模式

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).

当两个路由器第一次成为邻居时,它们在启动模式下交换拓扑表。对于路由器在启动模式期间接收到的每个目的地,它会以最大度量(有毒路由)将同一目的地播发回其新邻居。

5.4.2.2. Advertising Topology Table Change
5.4.2.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.

如果路由器使用一个邻居作为给定目的地的后继者,它将发送一个具有无穷大度量的目的地更新。

5.4.2.3. Sending a QUERY/UPDATE
5.4.2.3. 发送查询/更新

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遵循正常的拆分地平线规则。当通过查询或更新从后继者处接收到导致路由变为活动的度量更改时,路由器将向所有接口上的邻居发送查询,除了指向后继者的接口。

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.

如果路由器从其后继者处接收到查询,同时已对未导致其变为活动的事件做出反应,则可能会发生例外情况,例如,后继者的度量更改未导致活动转换,但随后是更新/查询,导致路由器变为活动。

5.5. EIGRP Metric Coefficients
5.5. EIGRP度量系数

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
        
               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。

5.5.1. Coefficients K1 and K2
5.5.1. 系数K1和K2

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可以使用基于吞吐量的路径选择的两种变体之一。

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,则作为接口报告的负载度量的拥塞效应将通过调整最大吞吐量来模拟“可用吞吐量”。

5.5.2. Coefficient K3
5.5.2. 系数K3

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使用接口提供的或计算为链路带宽因子的基于单向的值。

5.5.3. Coefficients K4 and K5
5.5.3. 系数K4和K5

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用于允许基于链路质量和分组丢失的路径选择。网络问题导致的数据包丢失会导致流媒体技术、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。

5.5.4. Coefficient K6
5.5.4. 系数K6

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的引入提供了广泛的度量支持,并用于允许扩展属性,这些属性可用于反映比能耗较低的属性更高的聚合度量。目前,在本文档的范围内定义了两个扩展属性:抖动和能量。

5.5.4.1. Jitter
5.5.4.1. 抖动

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)可用于填充此字段。

5.5.4.2. Energy
5.5.4.2. 能量

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)。

5.6. EIGRP Metric Calculations
5.6. EIGRP度量计算
5.6.1. Classic Metrics
5.6.1. 经典度量

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最初的目标之一是为IGRP提供和增强路由解决方案。为了实现这一点,EIGRP使用了与IGRP相同的复合度量,将这些项乘以256,将度量从24位更改为32位。

5.6.1.1. Classic Composite Formulation
5.6.1.1. 经典复合配方

EIGRP calculates the composite metric with the following formula:

EIGRP使用以下公式计算复合度量:

   metric = 256 * ({(K1*BW) + [(K2*BW)/(256-LOAD)] + (K3*DELAY)} *
            (K5/(REL+K4)))
        
   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%的可靠链路。Load是介于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)/BWmin

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:

延迟是到目标的传出接口延迟(以数十微秒为单位)的总和。延迟设置为它的最大值(十六进制0xFFFFFFFF)表示网络无法访问。延误的计算公式如下:

[sum of delays]

[延误总额]

The default composite metric, adjusted for scaling factors, for EIGRP is:

EIGRP的默认复合度量(针对比例因子进行了调整)为:

             metric = 256 * { [(10^7)/ BWmin] + [sum of delays]}
        
             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
        
               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)
        
            256 * sum of delay = 256 * 100 * 10 microseconds
                               = 25,600 (in tens of microseconds)
        
5.6.1.2. Cisco Interface Delay Compatibility
5.6.1.2. 思科接口延迟兼容性

For compatibility with Cisco products, the following table shows the times in nanoseconds EIGRP uses for bandwidth and delay.

为了与Cisco产品兼容,下表显示了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
        
   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
        
5.6.2. Wide Metrics
5.6.2. 宽度量

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根据通过链路所需的计算时间(以皮秒为单位)信息选择路径。

5.6.2.1. Wide Metric Vectors
5.6.2.1. 宽度量向量

EIGRP uses five "vector metrics": minimum Throughput, latency, load, reliability, and MTU. These values are calculated from destination to source as follows:

EIGRP使用五个“向量度量”:最小吞吐量、延迟、负载、可靠性和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:

还有两个附加值:抖动和能量。这两个值从目的地累加到来源:

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基于四种(带宽、延迟、可靠性和负载)路径选择方案中的任何一种来计算路径。这些方案是根据关键测量网络性能指标的选择来区分的。

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:

网络设计师注意:当试图通过接口带宽/延迟配置手动影响EIGRP路径选择时,由于以下原因,不鼓励修改带宽:

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.

仅当配置的值是整个路径上的最低带宽时,更改才会影响路径选择。改变带宽不仅会影响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节流;更改链路上配置的延迟仅影响度量计算。

5.6.2.2. Wide Metric Conversion Constants
5.6.2.2. 宽度量转换常数

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\u带宽10000000 EIGRP\u延迟\u微微1000000 EIGRP\u不可访问0xFFFFFFFFFFFFFFFFFFL EIGRP\u最大跳数100 EIGRP\u经典级256 EIGRP\u宽级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.

当使用上述单位计算度量时,所有容量信息将在使用前标准化为千字节和皮秒。例如,延迟以每千字节微秒表示,并将转换为每秒千字节;同样,能量将以每秒使用的千字节功率表示。

5.6.2.3. Throughput Calculation
5.6.2.3. 吞吐量计算

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)
        
                                  (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 * 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对度量的影响最大。

5.6.2.4. Latency Calculation
5.6.2.4. 延迟计算

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
        
                          Delay * EIGRP_WIDE_SCALE
        Latency = K3 *   --------------------------
                             EIGRP_DELAY_PICO
        
5.6.2.5. Composite Calculation
5.6.2.5. 综合计算
                                                                K5
      metric =[(K1*Net-Throughput) + Latency)+(K6*ExtAttr)] * ------
                                                              K4+Rel
        
                                                                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)) }
        
      metric = (K1 * min(Throughput)) + (K3 * sum(Latency)) }
        
6. EIGRP Packet Formats
6. EIGRP数据包格式
6.1. Protocol Number
6.1. 协议号

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多播地址的多播主机组地址[7]来传输HELLO数据包[13]。

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.

不要求两个EIGRP IPv6邻居在其连接接口上共享一个公共前缀。EIGRP IPv6将检查收到的HELLO是否包含有效的IPv6链路本地源地址。其他HELLO处理将遵循常见的EIGRP检查,包括匹配AS number和匹配K值。

6.2. Protocol Assignment Encoding
6.2. 协议分配编码

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

6.3. Destination Assignment Encoding
6.3. 目的地分配编码

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
        
         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
        
6.4. EIGRP Communities Attribute
6.4. EIGRP社区属性

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支持类似于BGP扩展社区RFC 4360[4]扩展类型的社区,类型字段由2个八位字节组成,值字段由6个八位字节组成。每个团体编码为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                |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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支持的知名社区(如原产地),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
        
       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
        
6.5. EIGRP Packet Header
6.5. EIGRP包头

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.

IPv4和IPv6的基本EIGRP数据包有效负载格式是相同的,尽管存在一些特定于协议的变化。数据包由一个报头和一组由类型/长度/值(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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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_更新1 EIGRP_OPC_请求2 EIGRP_OPC_查询3 EIGRP_OPC_回复4 EIGRP_OPC_问候5保留6(EIGRP_OPC_IPXSAP)保留7(EIGRP_OPC_探针)保留8(EIGRP_OPC_确认)保留9 EIGRP_OPC_SIA0查询10 EIGRP_OPC_SIA0回复11

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的补码和的标准补码。为了计算校验和,校验和字段的值为零。如果数据包校验和失败,则丢弃该数据包。

Flags: Defines special handling of the packet. There are currently four defined flag bits.

标志:定义数据包的特殊处理。目前有四个定义的标志位。

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.

初始化标志(0x01):此位在发送给新发现的邻居的初始更新中设置。它指示邻居公布其全套路由。

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标志(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标志(0x04):重启期间,在HELLO和更新数据包中设置重启标志。路由器查看RS标志以检测邻居是否正在重新启动。从重启路由器的角度来看,如果相邻路由器检测到RS标志集,它将保持相邻,并将在其更新数据包中设置RS标志,以指示它正在进行软重启。

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标志(0x08):表结束标志标记了与邻居的启动过程的结束。如果设置了该标志,则表示邻居已完成发送所有更新。在这一点上,路由器将删除重启事件之前从邻居那里学到的任何陈旧路由。陈旧路由是指在重新启动之前存在且未由邻居通过和更新刷新的任何路由。

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数据包应解码为ACK数据包,而不是HELLO数据包。

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到65535。

6.6. EIGRP TLV Encoding Format
6.6. EIGRP TLV编码格式

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.

每个数据包的内容可以包含可变数量的字段。每个字段都将被标记,并包含一个长度字段。这允许较新版本的软件添加功能,并与相同配置中的旧版本软件共存。可以跳过已标记但无法识别的字段。这种编码方案的另一个优点是,它允许多个网络层协议携带独立的信息。因此,如果以后决定实施单一的“集成”协议,这是可以做到的。

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)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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的格式不正确。

6.6.1. Type Field Encoding
6.6.1. 类型字段编码

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版本通用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定义。

6.6.2. Length Field Encoding
6.6.2. 长度字段编码

The Length field is a 2-octet unsigned number, which indicates the length of the TLV. The value includes the Type and Length fields.

长度字段是一个2-octet无符号数字,表示TLV的长度。该值包括类型和长度字段。

6.6.3. Value Field Encoding
6.6.3. 值字段编码

The Value field is a multi-octet field containing the payload for the TLV.

值字段是一个包含TLV有效载荷的多八位组字段。

6.7. EIGRP Generic TLV Definitions
6.7. EIGRP通用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
        
                                 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
        
6.7.1. 0x0001 - PARAMETER_TYPE
6.7.1. 0x0001-参数类型

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还用于初始更新数据包。

    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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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-1K2-0K3-1K4-0K5-0K6-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的邻居。认为邻居有效的路由器将存储邻居播发的所有路由信息。

6.7.2. 0x0002 - AUTHENTICATION_TYPE
6.7.2. 0x0002-身份验证类型

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)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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.

身份验证数据:“身份验证长度”反映的可变长度字段,取决于所使用的身份验证类型。一个认证类型TLV中可以存在多个认证类型。

6.7.2.1. 0x02 - MD5 Authentication Type
6.7.2.1. 0x02-MD5身份验证类型

MD5 Authentication will use Auth Type code 0x02, and the Auth Data will be the MD5 Hash value.

MD5身份验证将使用身份验证类型代码0x02,身份验证数据将是MD5哈希值。

6.7.2.2. 0x03 - SHA2 Authentication Type
6.7.2.2. 0x03-SHA2身份验证类型

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]哈希值。

6.7.3. 0x0003 - SEQUENCE_TYPE
6.7.3. 0x0003-序列类型

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              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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.

地址长度和协议地址将根据长度字段重复一次或多次。

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数据包中列出的每个地址都是不应进入有条件接收模式的邻居。

6.7.4. 0x0004 - SOFTWARE_VERSION_TYPE
6.7.4. 0x0004-软件版本类型

Field Length Vender OS major version 1 Vender OS minor version 1 EIGRP major revision 1 EIGRP minor revision 1

字段长度供应商操作系统主要版本1供应商操作系统次要版本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.|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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.|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
6.7.5. 0x0005 - MULTICAST_SEQUENCE_TYPE
6.7.5. 0x0005-多播\u序列\u类型

The next multicast SEQUENCE TLV.

下一个多播序列是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                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
6.7.6. 0x0006 - PEER_INFORMATION_TYPE
6.7.6. 0x0006-对等信息类型

This TLV is reserved, and not part of this document.

本TLV是保留的,不是本文件的一部分。

6.7.7. 0x0007 - PEER_ TERMINATION_TYPE
6.7.7. 0x0007-对等终端类型

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)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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除外)。

6.7.8. 0x0008 - TID_LIST_TYPE
6.7.8. 0x0008-TID列表类型

List of sub-topology identifiers, including the Base Topology, supported by the router.

路由器支持的子拓扑标识符列表,包括基本拓扑。

    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)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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

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将从邻居的拓扑列表中删除,并且通过该邻居为该子拓扑学习的所有路由将从拓扑表中删除。

6.8. Classic Route Information TLV Types
6.8. 经典路线信息TLV类型
6.8.1. Classic Flag Field Encoding
6.8.1. 经典标志字段编码

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.
        
   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.

活动(位2)-指示路由是否处于活动状态。

6.8.2. Classic Metric Encoding
6.8.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   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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的单位表示。延迟0xFFFFFF表示无法到达的路由。

Scaled Bandwidth: The path bandwidth measured in bits per second. In units of 2,560,000,000/kbps.

按比例缩放的带宽:路径带宽,以位/秒为单位。以2560000000/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.

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节。

6.8.3. Classic Exterior Encoding
6.8.3. 经典外部编码

Additional routing information so provided for destinations outside of the EIGRP AS as follows:

为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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Router Identifier (RID)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               External Autonomous System (AS) Number          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Administrative Tag                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    External Protocol Metric                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |Extern Protocol|  Flags Field  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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)编号:一个32位的编号,指示发送路由器所属的外部AS。如果源协议是EIGRP,则此字段将是[VRID,AS]对。如果外部协议没有AS,则可以使用其他信息(例如,Cisco将进程id用于OSPF)。

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节

6.8.4. Classic Destination Encoding
6.8.4. 经典目的地编码

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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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)
        
      IPv4: ((Bit Count - 1) / 8) + 1
      IPv6: (Bit Count == 128) ? 16 : ((x / 8) + 1)
        
6.8.5. IPv4-Specific TLVs
6.8.5. IPv4特定TLV

INTERNAL_TYPE 0x0102 EXTERNAL_TYPE 0x0103 COMMUNITY_TYPE 0x0104

内部类型0x0102外部类型0x0103社区类型0x0104

6.8.5.1. IPv4 INTERNAL_TYPE
6.8.5.1. IPv4内部\u类型

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)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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.

下一跳转发地址:由四个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节中的“目的地”说明。

6.8.5.2. IPv4 EXTERNAL_TYPE
6.8.5.2. IPv4外部\u类型

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目标和度量信息。此信息包括创建路由的路由协议的标识、外部度量、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)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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.

下一跳转发地址:由四个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节中的“目的地”说明。

6.8.5.3. IPv4 COMMUNITY_TYPE
6.8.5.3. IPv4社区类型

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)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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节中定义的一个或多个8-八位字节EIGRP社区。

6.8.6. IPv6-Specific TLVs
6.8.6. 特定于IPv6的TLV

INTERNAL_TYPE 0x0402 EXTERNAL_TYPE 0x0403 COMMUNITY_TYPE 0x0404

内部类型0x0402外部类型0x0403社区类型0x0404

6.8.6.1. IPv6 INTERNAL_TYPE
6.8.6.1. IPv6内部类型

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)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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位值(总共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节中的“目的地”说明。

6.8.6.2. IPv6 EXTERNAL_TYPE
6.8.6.2. IPv6外部类型

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目标和度量信息。此信息包括创建路由的路由协议的标识、外部度量、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)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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位值(总共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节中的“目的地”说明。

6.8.6.3 IPv6 COMMUNITY_TYPE
6.8.6.3 IPv6社区类型

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)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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节中定义的一个或多个8-八位字节EIGRP社区。

6.9. Multiprotocol Route Information TLV Types
6.9. 多协议路由信息TLV类型

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)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
6.9.1. TLV Header Encoding
6.9.1. TLV报头编码

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长期以来一直要求支持路由技术,如多拓扑,并提供独立于传输的目的地信息传输能力。为了实现这一点,一个向量被扩展为有一个新的“headerextensionheader”部分。这是一个可变长度字段,至少支持以下字段:

    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)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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

类型-拓扑TLV具有以下类型代码:类型高:0x06类型低:请求类型0x01内部类型0x02外部类型0x03

Router Identifier (RID): A 32-bit number provided by the router sourcing the information to uniquely identify it as the source.

路由器标识符(RID):路由器提供的一个32位数字,用于唯一标识信息源。

6.9.2. Wide Metric Encoding
6.9.2. 宽度量编码

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)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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-using优先级值中,具有较高优先级的目的地接收优惠待遇,并且在具有较低优先级的目的地之前被服务。值为零表示未设置优先级。

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.

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:

不透明标志:16位协议特定标志。Cisco当前定义的值为:

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

不透明\u SRCWD 0x01路由源撤回不透明\u CD 0x02候选默认路由不透明\u活动0x04路由当前处于活动状态不透明\u REPL 0x08路由从另一个VRF复制

Extended Attributes (Optional): When present, defines extendable per-destination attributes. This field is not normally transmitted.

扩展属性(可选):存在时,定义每个目标的可扩展属性。此字段通常不传输。

6.9.3. Extended Metrics
6.9.3. 扩展度量

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]的方式进行扩展。每个扩展度量应包括一个标题,标识类型(操作码)和长度(偏移量),后跟应用程序特定信息。未理解的扩展度量值必须视为不透明,并与相关路由一起传递。

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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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.

数据:由操作码定义的零个或多个八位字节的数据。

6.9.3.1. 0x00 - NoOp
6.9.3.1. 0x00-NoOp

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     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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.

数据:此属性不存在任何数据。

6.9.3.2. 0x01 - Scaled Metric
6.9.3.2. 0x01-缩放度量

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.

如果从后退邻居接收到路由,并且该路由被选择为最佳路径,则在较旧更新中接收到的缩放度量可以附加到分组。如果收到,该值仅供参考,不受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                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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.

缩放带宽:沿路径的最小带宽,单位为2560000000/kbps。带宽为0xFFFFFF表示无法到达的路由。

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的单位表示。延迟0xFFFFFF表示无法到达的路由。

6.9.3.3. 0x02 - Administrator Tag
6.9.3.3. 0x02-管理员标签

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.)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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边界路由器中的路由。

6.9.3.4. 0x03 - Community List
6.9.3.4. 0x03-社区列表

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)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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节中定义的一个或多个8-八位字节EIGRP社区。

6.9.3.5. 0x04 - Jitter
6.9.3.5. 0x04-抖动

(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            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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.

抖动:网络中延迟随时间变化的度量,以微秒为单位。

6.9.3.6. 0x05 - Quiescent Energy
6.9.3.6. 0x05-静态能量

(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)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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-能量:空闲(备用)能量使用率较高的路径将反映在比能量使用率较低的路径更高的聚合度量中。如果存在,该数字将表示空闲功耗,单位为毫瓦/千比特。

6.9.3.7. 0x06 - Energy
6.9.3.7. 0x06-能量

(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)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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.

能量:与能量使用率较低的路径相比,具有较高活动能量使用率的路径将反映在较高的聚合度量中。如果存在,该数字将表示功耗,单位为毫瓦/千比特。

6.9.3.8. 0x07 - AddPath
6.9.3.8. 0x07-添加路径

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能够将多个最佳路径播发到相邻位置。最多支持四个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) |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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数据而有所不同。

6.9.3.8.1. AddPath with IPv4 Next Hop
6.9.3.8.1. 使用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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       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   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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.

下一跳地址:由四个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:

如果路由类型为external,则将添加两个额外字节,如下所示:

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节。

6.9.3.8.2. AddPath with IPv6 Next Hop
6.9.3.8.2. 使用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 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 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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位值(总共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位管理标签。这允许网络管理员基于此值筛选路由。如果路由类型为外部,则将按如下方式添加两个附加字节:

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节。

6.9.4. Exterior Encoding
6.9.4. 外部编码

Additional routing information provided for destinations outside of the EIGRP AS as follows:

为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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Router Identifier (RID)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            External Autonomous System (AS) Number             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     External Protocol Metric                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Reserved             |Extern Protocol| Flags Field |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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)编号:一个32位的编号,指示发送路由器所属的外部AS。如果源协议是EIGRP,则此字段将是[VRID,AS]对。如果外部协议没有AS,则可以使用其他信息(例如,Cisco将进程id用于OSPF)。

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节。

6.9.5. Destination Encoding
6.9.5. 目的地编码

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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        
    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)
        
      IPv4: ((Bit Count - 1) / 8) + 1
      IPv6: (Bit Count == 128) ? 16 : ((x / 8) + 1)
        
6.9.6. Route Information
6.9.6. 路线信息
6.9.6.1. INTERNAL TYPE
6.9.6.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标题中定义的IANA AFI(见第6.9.1节)和相关度量信息传送目的地信息。此TLV中公布的路由是EIGRP配置的网络接口,以及通过运行EIGRP的其他路由器学习的网络。

6.9.6.2. EXTERNAL TYPE
6.9.6.2. 外型

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报头中定义的IANA AFI(见第6.9.1节)和EIGRP注入AS的其他路由协议学习的路由的度量信息传送目的地信息。此信息包括创建路由的路由协议的标识、外部度量、AS编号、是否应标记为EIGRP AS一部分的指示符,以及用于EIGRP AS边界处路由筛选的网络管理员标记。

7. Security Considerations
7. 安全考虑

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的可伸缩性提出了挑战,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]。

8. IANA Considerations
8. IANA考虑

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。它还用作协议编号88(EIGRP)[15]的分配。

9. References
9. 工具书类
9.1. Normative References
9.1. 规范性引用文件

[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,J.J.,“使用距离向量或链路状态的无环路路由的统一方法”,SIGCOMM'89,通信体系结构与协议研讨会论文集,第19卷,第212-223页,ACM 089791-332-9/89/0009/0212,DOI 10.1145/75247.752681989。

[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国际网络信息系统中心,发表于IEEE/ACM网络交易,第1卷,第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] Rosen,E.和Y.Rekhter,“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.,“分配被认为有用的实验和测试数字”,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.,“互联网协议”,标准5,RFC 791,DOI 10.17487/RFC07911981年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>.

9.2. Informative References
9.2. 资料性引用

[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,“地址家庭号码”<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多播地址空间注册表”<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多播地址空间注册表”<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.

感谢迪诺·法里纳奇、鲍勃·奥尔布赖特森和戴夫·卡茨。他们在设计和开发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.

特别感谢思科工程师的核心团队,他们的奉献精神、漫长的工作时间和辛勤的工作在过去十年中引领了EIGRP的发展。他们是唐尼·萨维奇、米克尔·拉维扎、海蒂·欧、黎明·李、图安·特兰、凯瑟琳·特兰、唐·斯莱、克劳德·卡特尔、唐纳德·夏普、史蒂文·摩尔、理查德·韦勒姆、雷·罗姆尼、吉姆·莫尔曼、丹尼斯·温德、克里斯·范·霍维恩、杰拉尔德·雷德温、格伦·马修斯、迈克尔·维比和其他人。

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:

除了Cisco工程师多年来不懈的努力外,我们还想亲自表彰创建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.美国北卡罗来纳州莫里斯维尔RTP Kit Creek路7025号电话: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.美国北卡罗来纳州莫里斯维尔RTP Kit Creek路7025号电话: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.美国北卡罗来纳州莫里斯维尔RTP Kit Creek路7025号电话:408-895-2031电子邮件:smoore@cisco.com

Donald Slice Cumulus Networks Apex, NC United States Email: dslice@cumulusnetworks.com

美国北卡罗来纳州Donald Slice Cumulus Networks Apex电子邮件:dslice@cumulusnetworks.com

Peter Paluch University of Zilina Univerzitna 8215/1, Zilina 01026 Slovakia Phone: 421-905-164432 Email: Peter.Paluch@fri.uniza.sk

彼得帕鲁奇大学Ziina UnvirZITNA 8215/1,Ziina 01026斯洛伐克电话:421-905-16432电子邮件:彼得。Paluch@fri.uniza.sk

Russ White LinkedIn Apex, NC United States Phone: 1-877-308-0993 Email: russw@riw.us

Russ White LinkedIn Apex,北卡罗来纳州美国电话:1-877-308-0993电子邮件:russw@riw.us