File: rfc7868.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (4477 lines) | stat: -rw-r--r-- 213,829 bytes
parent folder | download | duplicates (2)
<pre>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


       <span class="h1">Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)</span>

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.

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 <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc7868">http://www.rfc-editor.org/info/rfc7868</a>.











<span class="grey">Savage, et al.                Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.

   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.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-5">5</a>
   <a href="#section-2">2</a>. Conventions .....................................................<a href="#page-5">5</a>
      <a href="#section-2.1">2.1</a>. Requirements Language ......................................<a href="#page-5">5</a>
      <a href="#section-2.2">2.2</a>. Terminology ................................................<a href="#page-5">5</a>
   <a href="#section-3">3</a>. The Diffusing Update Algorithm (DUAL) ...........................<a href="#page-9">9</a>
      <a href="#section-3.1">3.1</a>. Algorithm Description ......................................<a href="#page-9">9</a>
      <a href="#section-3.2">3.2</a>. Route States ..............................................<a href="#page-10">10</a>
      <a href="#section-3.3">3.3</a>. Feasibility Condition .....................................<a href="#page-11">11</a>
      <a href="#section-3.4">3.4</a>. DUAL Message Types ........................................<a href="#page-13">13</a>
      <a href="#section-3.5">3.5</a>. DUAL Finite State Machine (FSM) ...........................<a href="#page-13">13</a>
      <a href="#section-3.6">3.6</a>. DUAL Operation -- Example Topology ........................<a href="#page-18">18</a>
   <a href="#section-4">4</a>. EIGRP Packets ..................................................<a href="#page-20">20</a>
      <a href="#section-4.1">4.1</a>. UPDATE Packets ............................................<a href="#page-21">21</a>
      <a href="#section-4.2">4.2</a>. QUERY Packets .............................................<a href="#page-21">21</a>
      <a href="#section-4.3">4.3</a>. REPLY Packets .............................................<a href="#page-22">22</a>
      <a href="#section-4.4">4.4</a>. Exception Handling ........................................<a href="#page-22">22</a>
           <a href="#section-4.4.1">4.4.1</a>. Active Duration (SIA) ..............................<a href="#page-22">22</a>
                  <a href="#section-4.4.1.1">4.4.1.1</a>. SIA-QUERY .................................<a href="#page-23">23</a>
                  <a href="#section-4.4.1.2">4.4.1.2</a>. SIA-REPLY .................................<a href="#page-24">24</a>
   <a href="#section-5">5</a>. EIGRP Operation ................................................<a href="#page-25">25</a>
      <a href="#section-5.1">5.1</a>. Finite State Machine ......................................<a href="#page-25">25</a>
      <a href="#section-5.2">5.2</a>. Reliable Transport Protocol ...............................<a href="#page-25">25</a>
           <a href="#section-5.2.1">5.2.1</a>. Bandwidth on Low-Speed Links .......................<a href="#page-32">32</a>
      <a href="#section-5.3">5.3</a>. Neighbor Discovery/Recovery ...............................<a href="#page-32">32</a>
           <a href="#section-5.3.1">5.3.1</a>. Neighbor Hold Time .................................<a href="#page-32">32</a>
           <a href="#section-5.3.2">5.3.2</a>. HELLO Packets ......................................<a href="#page-33">33</a>
           <a href="#section-5.3.3">5.3.3</a>. UPDATE Packets .....................................<a href="#page-33">33</a>
           <a href="#section-5.3.4">5.3.4</a>. Initialization Sequence ............................<a href="#page-34">34</a>
           <a href="#section-5.3.5">5.3.5</a>. Neighbor Formation .................................<a href="#page-35">35</a>
           <a href="#section-5.3.6">5.3.6</a>. QUERY Packets during Neighbor Formation ............<a href="#page-35">35</a>



<span class="grey">Savage, et al.                Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


      <a href="#section-5.4">5.4</a>. Topology Table ............................................<a href="#page-36">36</a>
           <a href="#section-5.4.1">5.4.1</a>. Route Management ...................................<a href="#page-36">36</a>
                  <a href="#section-5.4.1.1">5.4.1.1</a>. Internal Routes ...........................<a href="#page-37">37</a>
                  <a href="#section-5.4.1.2">5.4.1.2</a>. External Routes ...........................<a href="#page-37">37</a>
           <a href="#section-5.4.2">5.4.2</a>. Split Horizon and Poison Reverse ...................<a href="#page-38">38</a>
                  <a href="#section-5.4.2.1">5.4.2.1</a>. Startup Mode ..............................<a href="#page-38">38</a>
                  <a href="#section-5.4.2.2">5.4.2.2</a>. Advertising Topology Table Change .........<a href="#page-39">39</a>
                  <a href="#section-5.4.2.3">5.4.2.3</a>. Sending a QUERY/UPDATE ....................<a href="#page-39">39</a>
      <a href="#section-5.5">5.5</a>. EIGRP Metric Coefficients .................................<a href="#page-39">39</a>
           <a href="#section-5.5.1">5.5.1</a>. Coefficients K1 and K2 .............................<a href="#page-40">40</a>
           <a href="#section-5.5.2">5.5.2</a>. Coefficient K3 .....................................<a href="#page-40">40</a>
           <a href="#section-5.5.3">5.5.3</a>. Coefficients K4 and K5 .............................<a href="#page-40">40</a>
           <a href="#section-5.5.4">5.5.4</a>. Coefficient K6 .....................................<a href="#page-41">41</a>
                  <a href="#section-5.5.4.1">5.5.4.1</a>. Jitter ....................................<a href="#page-41">41</a>
                  <a href="#section-5.5.4.2">5.5.4.2</a>. Energy ....................................<a href="#page-41">41</a>
      <a href="#section-5.6">5.6</a>. EIGRP Metric Calculations .................................<a href="#page-41">41</a>
           <a href="#section-5.6.1">5.6.1</a>. Classic Metrics ....................................<a href="#page-41">41</a>
                  <a href="#section-5.6.1.1">5.6.1.1</a>. Classic Composite Formulation .............<a href="#page-42">42</a>
                  <a href="#section-5.6.1.2">5.6.1.2</a>. Cisco Interface Delay Compatibility .......<a href="#page-43">43</a>
           <a href="#section-5.6.2">5.6.2</a>. Wide Metrics .......................................<a href="#page-43">43</a>
                  <a href="#section-5.6.2.1">5.6.2.1</a>. Wide Metric Vectors .......................<a href="#page-44">44</a>
                  <a href="#section-5.6.2.2">5.6.2.2</a>. Wide Metric Conversion Constants ..........<a href="#page-45">45</a>
                  <a href="#section-5.6.2.3">5.6.2.3</a>. Throughput Calculation ....................<a href="#page-45">45</a>
                  <a href="#section-5.6.2.4">5.6.2.4</a>. Latency Calculation .......................<a href="#page-46">46</a>
                  <a href="#section-5.6.2.5">5.6.2.5</a>. Composite Calculation .....................<a href="#page-46">46</a>
   <a href="#section-6">6</a>. EIGRP Packet Formats ...........................................<a href="#page-46">46</a>
      <a href="#section-6.1">6.1</a>. Protocol Number ...........................................<a href="#page-46">46</a>
      <a href="#section-6.2">6.2</a>. Protocol Assignment Encoding ..............................<a href="#page-47">47</a>
      <a href="#section-6.3">6.3</a>. Destination Assignment Encoding ...........................<a href="#page-47">47</a>
      <a href="#section-6.4">6.4</a>. EIGRP Communities Attribute ...............................<a href="#page-48">48</a>
      <a href="#section-6.5">6.5</a>. EIGRP Packet Header .......................................<a href="#page-49">49</a>
      <a href="#section-6.6">6.6</a>. EIGRP TLV Encoding Format .................................<a href="#page-51">51</a>
           <a href="#section-6.6.1">6.6.1</a>. Type Field Encoding ................................<a href="#page-52">52</a>
           <a href="#section-6.6.2">6.6.2</a>. Length Field Encoding ..............................<a href="#page-52">52</a>
           <a href="#section-6.6.3">6.6.3</a>. Value Field Encoding ...............................<a href="#page-52">52</a>
      <a href="#section-6.7">6.7</a>. EIGRP Generic TLV Definitions .............................<a href="#page-52">52</a>
           <a href="#section-6.7.1">6.7.1</a>. 0x0001 - PARAMETER_TYPE ............................<a href="#page-53">53</a>
           <a href="#section-6.7.2">6.7.2</a>. 0x0002 - AUTHENTICATION_TYPE .......................<a href="#page-53">53</a>
                  <a href="#section-6.7.2.1">6.7.2.1</a>. 0x02 - MD5 Authentication Type ............<a href="#page-54">54</a>
                  <a href="#section-6.7.2.2">6.7.2.2</a>. 0x03 - SHA2 Authentication Type ...........<a href="#page-54">54</a>
           <a href="#section-6.7.3">6.7.3</a>. 0x0003 - SEQUENCE_TYPE .............................<a href="#page-54">54</a>
           <a href="#section-6.7.4">6.7.4</a>. 0x0004 - SOFTWARE_VERSION_TYPE .....................<a href="#page-55">55</a>
           <a href="#section-6.7.5">6.7.5</a>. 0x0005 - MULTICAST_SEQUENCE_TYPE ...................<a href="#page-55">55</a>
           <a href="#section-6.7.6">6.7.6</a>. 0x0006 - PEER_INFORMATION_TYPE .....................<a href="#page-55">55</a>
           <a href="#section-6.7.7">6.7.7</a>. 0x0007 - PEER_ TERMINATION_TYPE ....................<a href="#page-56">56</a>
           <a href="#section-6.7.8">6.7.8</a>. 0x0008 - TID_LIST_TYPE .............................<a href="#page-56">56</a>
      <a href="#section-6.8">6.8</a>. Classic Route Information TLV Types .......................<a href="#page-57">57</a>
           <a href="#section-6.8.1">6.8.1</a>. Classic Flag Field Encoding ........................<a href="#page-57">57</a>



<span class="grey">Savage, et al.                Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


           <a href="#section-6.8.2">6.8.2</a>. Classic Metric Encoding ............................<a href="#page-57">57</a>
           <a href="#section-6.8.3">6.8.3</a>. Classic Exterior Encoding ..........................<a href="#page-58">58</a>
           <a href="#section-6.8.4">6.8.4</a>. Classic Destination Encoding .......................<a href="#page-59">59</a>
           <a href="#section-6.8.5">6.8.5</a>. IPv4-Specific TLVs .................................<a href="#page-59">59</a>
                  <a href="#section-6.8.5.1">6.8.5.1</a>. IPv4 INTERNAL_TYPE ........................<a href="#page-60">60</a>
                  <a href="#section-6.8.5.2">6.8.5.2</a>. IPv4 EXTERNAL_TYPE ........................<a href="#page-60">60</a>
                  <a href="#section-6.8.5.3">6.8.5.3</a>. IPv4 COMMUNITY_TYPE .......................<a href="#page-62">62</a>
           <a href="#section-6.8.6">6.8.6</a>. IPv6-Specific TLVs .................................<a href="#page-62">62</a>
                  <a href="#section-6.8.6.1">6.8.6.1</a>. IPv6 INTERNAL_TYPE ........................<a href="#page-63">63</a>
                  <a href="#section-6.8.6.2">6.8.6.2</a>. IPv6 EXTERNAL_TYPE ........................<a href="#page-63">63</a>
                  <a href="#section-6.8.6.3">6.8.6.3</a>. IPv6 COMMUNITY_TYPE .......................<a href="#page-65">65</a>
      <a href="#section-6.9">6.9</a>. Multiprotocol Route Information TLV Types .................<a href="#page-66">66</a>
           <a href="#section-6.9.1">6.9.1</a>. TLV Header Encoding ................................<a href="#page-66">66</a>
           <a href="#section-6.9.2">6.9.2</a>. Wide Metric Encoding ...............................<a href="#page-67">67</a>
           <a href="#section-6.9.3">6.9.3</a>. Extended Metrics ...................................<a href="#page-68">68</a>
                  <a href="#section-6.9.3.1">6.9.3.1</a>. 0x00 - NoOp ...............................<a href="#page-69">69</a>
                  <a href="#section-6.9.3.2">6.9.3.2</a>. 0x01 - Scaled Metric ......................<a href="#page-70">70</a>
                  <a href="#section-6.9.3.3">6.9.3.3</a>. 0x02 - Administrator Tag ..................<a href="#page-70">70</a>
                  <a href="#section-6.9.3.4">6.9.3.4</a>. 0x03 - Community List .....................<a href="#page-71">71</a>
                  <a href="#section-6.9.3.5">6.9.3.5</a>. 0x04 - Jitter .............................<a href="#page-71">71</a>
                  <a href="#section-6.9.3.6">6.9.3.6</a>. 0x05 - Quiescent Energy ...................<a href="#page-71">71</a>
                  <a href="#section-6.9.3.7">6.9.3.7</a>. 0x06 - Energy .............................<a href="#page-72">72</a>
                  <a href="#section-6.9.3.8">6.9.3.8</a>. 0x07 - AddPath ............................<a href="#page-72">72</a>
                           <a href="#section-6.9.3.8.1">6.9.3.8.1</a>. AddPath with IPv4 Next Hop .....<a href="#page-73">73</a>
                           <a href="#section-6.9.3.8.2">6.9.3.8.2</a>. AddPath with IPv6 Next Hop .....<a href="#page-74">74</a>
           <a href="#section-6.9.4">6.9.4</a>. Exterior Encoding ..................................<a href="#page-75">75</a>
           <a href="#section-6.9.5">6.9.5</a>. Destination Encoding ...............................<a href="#page-76">76</a>
           <a href="#section-6.9.6">6.9.6</a>. Route Information ..................................<a href="#page-76">76</a>
                  <a href="#section-6.9.6.1">6.9.6.1</a>. INTERNAL TYPE .............................<a href="#page-76">76</a>
                  <a href="#section-6.9.6.2">6.9.6.2</a>. EXTERNAL TYPE .............................<a href="#page-76">76</a>
   <a href="#section-7">7</a>. Security Considerations ........................................<a href="#page-77">77</a>
   <a href="#section-8">8</a>. IANA Considerations ............................................<a href="#page-77">77</a>
   <a href="#section-9">9</a>. References .....................................................<a href="#page-77">77</a>
      <a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-77">77</a>
      <a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-78">78</a>
   Acknowledgments ...................................................<a href="#page-79">79</a>
   Authors' Addresses ................................................<a href="#page-80">80</a>














<span class="grey">Savage, et al.                Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   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 [<a href="#ref-3" title="&quot;Loop-Free Routing using Diffusing Computations&quot;">3</a>].  The Diffusing Update Algorithm (DUAL) is the
   algorithm used to obtain loop freedom at every instant throughout a
   route computation [<a href="#ref-2" title="&quot;A Unified Approach to Loop-Free Routing Using Distance Vectors or Link States&quot;">2</a>].  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.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Conventions</span>

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Requirements Language</span>

   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 <a href="./rfc2119">RFC 2119</a> [<a href="#ref-1" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">1</a>].

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Terminology</span>

   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 [<a href="#ref-12" title="&quot;Address Family Numbers&quot;">12</a>].

   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.









<span class="grey">Savage, et al.                Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


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

   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.

   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.

   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 [<a href="#ref-3" title="&quot;Loop-Free Routing using Diffusing Computations&quot;">3</a>].

   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.

   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.




<span class="grey">Savage, et al.                Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   Feasible Distance (FD):
      Defined as the least-known total metric to a destination from the
      current router since the last transition from ACTIVE to PASSIVE
      state.  Being effectively a record of the smallest known metric
      since the last time the network entered the PASSIVE state, the FD
      is not necessarily a metric of the current best path.  Exactly one
      FD is computed per destination network.

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

   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.

   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.

   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.





<span class="grey">Savage, et al.                Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


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

   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.

   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.

   Topology Identifier (TID):
      A number that is used to mark prefixes as belonging to a specific
      sub-topology.

   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.

   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.

   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.



<span class="grey">Savage, et al.                Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   VID:
      VLAN Identifier

   Virtual Routing and Forwarding (VRF):
      Independent Virtual Private Network (VPN) routing/forwarding
      tables that coexist within the same router at the same time.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  The Diffusing Update Algorithm (DUAL)</span>

   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.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Algorithm Description</span>

   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 [<a href="#ref-10" title="&quot;OSPF Version 2&quot;">10</a>].  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.

   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.

   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.



<span class="grey">Savage, et al.                Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Route States</span>

   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.

   More exactly, the two states are defined as follows:

   o Passive

      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

      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.



<span class="grey">Savage, et al.                Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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
   <a href="#section-3.5">Section 3.5</a>.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Feasibility Condition</span>

   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:



<span class="grey">Savage, et al.                Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


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

   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.




<span class="grey">Savage, et al.                Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  DUAL Message Types</span>

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

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

   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 REPLY - sent in response to a QUERY or SIA-QUERY

   In addition to these three basic types, two additional sub-types have
   been added to 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-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.

   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.

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  DUAL Finite State Machine (FSM)</span>

   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.

   When there are no Feasible Successors but there are neighbors
   advertising the destination, a recalculation must occur to determine
   a new successor.



<span class="grey">Savage, et al.                Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

   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.







































<span class="grey">Savage, et al.                Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


              +------------+                +-----------+
              |             \              /            |
              |              \            /             |
              |   +=================================+   |
              |   |                                 |   |
              |(1)|             Passive             |(2)|
              +--&gt;|                                 |&lt;--+
                  +=================================+
                      ^     |    ^    ^    ^    |
                  (14)|     |(15)|    |(13)|    |
                      |  (4)|    |(16)|    | (3)|
                      |     |    |    |    |    +------------+
                      |     |    |    |    |                  \
             +-------+      +    +    |    +-------------+     \
            /              /    /     |                   \     \
           /              /    /      +----+               \     \
          |               |   |            |                |     |
          |               v   |            |                |     v
      +==========+(11) +==========+     +==========+(12) +==========+
      |  Active  |----&gt;|  Active  |(5)  |  Active  |----&gt;|  Active  |
      |          |  (9)|          |----&gt;|          | (10)|          |
      |  oij=0   |&lt;----|  oij=1   |     |  oij=2   |&lt;----|  oij=3   |
   +--|          |  +--|          |  +--|          |  +--|          |
   |  +==========+  |  +==========+  |  +==========+  |  +==========+
   |      ^   |(5)  |      ^         |    ^    ^      |         ^
   |      |   +-----|------|---------|----+    |      |         |
   +------+         +------+         +---------+      +---------+
   (6,7,8)          (6,7,8)            (6,7,8)          (6,7,8)

                      Figure 1: DUAL Finite State Machine

   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






<span class="grey">Savage, et al.                Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

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

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

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

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










<span class="grey">Savage, et al.                Informational                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


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

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

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

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

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

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

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






<span class="grey">Savage, et al.                Informational                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


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

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

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

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

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

<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>.  DUAL Operation -- Example Topology</span>

   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.











<span class="grey">Savage, et al.                Informational                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


                                N
                                |
                             (1)A ---&lt;--- B(2)
                                |         |
                                ^         |
                                |         |
                             (2)D ---&lt;--- C(3)

                        Figure 2: Stable Topology

   In the case where the link between A and D fails (Figure 3);

          N                                   N
          |                                   |
          A ---&lt;--- B                         A ---&lt;--- B
          |         |                         |          |
          X         |                         ^          |
          |         |                         |          |
          D ---&lt;--- C                         D ---&lt;--- C
            Q-&gt;                                      &lt;-R

                             N
                             |
                          (1)A ---&lt;--- B(2)
                                       |
                                       ^
                                       |
                          (4)D ---&gt;--- C(3)

                  Figure 3: Link between A and D Fails


      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.

   Notice that nodes A and B were not involved in the recalculation
   since they were not affected by the change.





<span class="grey">Savage, et al.                Informational                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

   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.

          N                                N
          |                                |
       (1)A ---&lt;--- 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

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  EIGRP Packets</span>

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

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

   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.






<span class="grey">Savage, et al.                Informational                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

   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" [<a href="#ref-13" title="&quot;IPv4 Multicast Address Space Registry&quot;">13</a>]
      FF02:0:0:0:0:0:0:A for IPv6 "EIGRP Routers" [<a href="#ref-14" title="&quot;IPv6 Multicast Address Space Registry&quot;">14</a>]

   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.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  UPDATE Packets</span>

   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.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  QUERY Packets</span>

   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.



<span class="grey">Savage, et al.                Informational                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  REPLY Packets</span>

   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.

   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.

   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.

   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.

<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Exception Handling</span>

<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a>.  Active Duration (SIA)</span>

   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.

   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.

   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



<span class="grey">Savage, et al.                Informational                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

   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.

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

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

      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.

   Implementation note: Cisco currently implements option (b).

<span class="h5"><a class="selflink" id="section-4.4.1.1" href="#section-4.4.1.1">4.4.1.1</a>.  SIA-QUERY</span>

   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.

   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.

   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.






<span class="grey">Savage, et al.                Informational                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

   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.

   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:

      1) Acknowledge the receipt of the packet

      2) Send a REPLY if a successor exists

      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

<span class="h5"><a class="selflink" id="section-4.4.1.2" href="#section-4.4.1.2">4.4.1.2</a>.  SIA-REPLY</span>

   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.

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

   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.







<span class="grey">Savage, et al.                Informational                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. EIGRP Operation</span>

   EIGRP has four basic components:

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

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Finite State Machine</span>

   The detail of DUAL, the State Machine used by EIGRP, is covered in
   <a href="#section-3.5">Section 3.5</a>.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Reliable Transport Protocol</span>

   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.

   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.

   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.











<span class="grey">Savage, et al.                Informational                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   The following sequence number rules must be met for the EIGRP
   reliable transport protocol to work correctly:

      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  Any packets that do not require acknowledgment must be sent
         with a sequence number of 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  Packets that are network-layer multicast must contain
         acknowledgment number of 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.

   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.

   Duplicate packets are also discarded upon receipt.  Acknowledgments
   are not accumulative.  Therefore, an ACK with a non-zero sequence
   number acknowledges a single packet.



<span class="grey">Savage, et al.                Informational                    [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

   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.

   This example will assume no packet loss.

Router A                          Router B

                An Example UPDATE Exchange
                                 &lt;----------------
                                 UPDATE (multicast)
A receives packet                SEQ=100, ACK=0
                                 Add packet to A's retransmit list
----------------&gt;
ACK (unicast)
SEQ=0, ACK=100                   Receive ACK
Process UPDATE                   Delete packet from A's retransmit list

                An Example QUERY Exchange
                                 &lt;----------------
                                 QUERY (multicast)
A receives packet                SEQ=101, ACK=0
Process QUERY                    Add packet to A's retransmit list

----------------&gt;
REPLY (unicast)
SEQ=201, ACK=101                 Process ACK
                                 Delete packet from A's retransmit
list
                                 Process REPLY packet
                                 &lt;----------------
                                 ACK (unicast)
A receives packet                SEQ=0, ACK=201

       Figure 5: Reliable Transfer on Point-to-Point Links





<span class="grey">Savage, et al.                Informational                    [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

   This example will assume there is heavy packet loss on a network.

Router A                           Router B
                                 &lt;----------------
                                 UPDATE (multicast)
A receives packet                SEQ=100, ACK=0
                                 Add packet to A's retransmit list
----------------&gt;
ACK (unicast)
SEQ=0, ACK=100                   Receive ACK
Process UPDATE                   Delete packet from A's retransmit list

                                 &lt;--/LOST/--------------
                                 UPDATE (multicast)
                                 SEQ=101, ACK=0
                                 Add packet to A's retransmit list

                                 Retransmit Timer Expires
                                 &lt;----------------
                                 Retransmit UPDATE (unicast)
                                 SEQ=101, ACK=0
                                 Keep packet on A's retransmit list
----------------&gt;
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

   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.

           Router B -----------+
                               |
           Router C -----------+------------ Router A
                               |
           Router D -----------+





<span class="grey">Savage, et al.                Informational                    [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


                        An Example UPDATE Exchange
                                  &lt;----------------
                                  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
----------------&gt;
B sends ACK (unicast)
SEQ=0, ACK=100                    Receive ACK
Process UPDATE                    Delete packet from B's retransmit list

----------------&gt;
C sends ACK (unicast)
SEQ=0, ACK=100                    Receive ACK
Process UPDATE                    Delete packet from C's retransmit list

----------------&gt;
D sends ACK (unicast)
SEQ=0, ACK=100                    Receive ACK
Process UPDATE                    Delete packet from D's retransmit list

                         An Example QUERY Exchange
                                  &lt;----------------
                                  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

----------------&gt;
B sends REPLY (unicast)           &lt;----------------
SEQ=511, ACK=101                  A sends ACK (unicast to B)
Process UPDATE                    SEQ=0, ACK=511
                                  Delete packet from B's retransmit list
----------------&gt;
C sends REPLY (unicast)           &lt;----------------
SEQ=200, ACK=101                  A sends ACK (unicast to C)
Process UPDATE                    SEQ=0, ACK=200
                                  Delete packet from C's retransmit list

----------------&gt;
D sends REPLY (unicast)           &lt;----------------
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



<span class="grey">Savage, et al.                Informational                    [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   And finally, a situation where numerous multicast and unicast packets
   are sent close together in a multi-access environment is illustrated
   in Figure 8.

        Router B -----------+
                            |
        Router C -----------+------------ Router A
                            |
        Router D -----------+

                                &lt;----------------
                                A sends UPDATE (multicast)
                                SEQ=100, ACK=0
---------------/LOST/-&gt;         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

----------------&gt;
C sends ACK (unicast)
SEQ=0, ACK=100                  Delete packet from C's retransmit list

----------------&gt;
D sends ACK (unicast)
SEQ=0, ACK=100                  Delete packet from D's retransmit list
                                &lt;----------------
                                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

                                &lt;----------------
                                A sends UPDATE (multicast)
                                SEQ=101, ACK=0, CR-Flag=1
---------------/LOST/-&gt;         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

----------------&gt;
C sends ACK (unicast)
SEQ=0, ACK=101






<span class="grey">Savage, et al.                Informational                    [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


----------------&gt;
D sends ACK (unicast)

SEQ=0, ACK=101
                                &lt;----------------
                                A resends UPDATE (unicast to B)
                                SEQ=100, ACK=0
B packet duplicate

---------------&gt;
B sends ACK (unicast)           A removes packet from retransmit list
SEQ=0, ACK=100
                                &lt;----------------
                                A resends UPDATE (unicast to B)
                                SEQ=101, ACK=0

---------------&gt;
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

   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.

   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.

   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.

   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.

   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.



<span class="grey">Savage, et al.                Informational                    [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

   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.

<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>.  Bandwidth on Low-Speed Links</span>

   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:

      1. Generate more traffic than the interface can handle, possibly
         causing drops, thereby impairing EIGRP performance.

      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.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Neighbor Discovery/Recovery</span>

   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.

<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>.  Neighbor Hold Time</span>

   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.




<span class="grey">Savage, et al.                Informational                    [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>.  HELLO Packets</span>

   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.

<span class="h4"><a class="selflink" id="section-5.3.3" href="#section-5.3.3">5.3.3</a>.  UPDATE Packets</span>

   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.

   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.

   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.

   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.










<span class="grey">Savage, et al.                Informational                    [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h4"><a class="selflink" id="section-5.3.4" href="#section-5.3.4">5.3.4</a>.  Initialization Sequence</span>

            Router A                           Router B
          (just booted)                    (up and running)

        (1)----------------&gt;
             HELLO (multicast)           &lt;----------------     (2)
             SEQ=0, ACK=0                 HELLO (multicast)
                                          SEQ=0, ACK=0

                                         &lt;----------------     (3)
                                          UPDATE (unicast)
                                          SEQ=10, ACK=0, INIT
        (4)----------------&gt;              UPDATE 11 is queued
             UPDATE (unicast)
             SEQ=100, ACK=10, INIT       &lt;----------------     (5)
                                         UPDATE (unicast)
                                         SEQ=11, ACK=100
                                         All UPDATES sent
        (6)--------------/lost/-&gt;
             ACK (unicast)
             SEQ=0, ACK=11
                                         (5 seconds later)
                                         &lt;----------------     (7)
             Duplicate received,         UPDATE (unicast)
             packet discarded            SEQ=11, ACK=100
        (8)---------------&gt;
             ACK (unicast)
             SEQ=0, ACK=11

                    Figure 9: Initialization Sequence

   (1) Router A sends a multicast HELLO and Router B discovers it.

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

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







<span class="grey">Savage, et al.                Informational                    [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


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

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

   (6) Router B later retransmits the UPDATE packet to Router 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.

<span class="h4"><a class="selflink" id="section-5.3.5" href="#section-5.3.5">5.3.5</a>.  Neighbor Formation</span>

   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 (<a href="#section-5.2">Section 5.2</a>).

   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:

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

<span class="h4"><a class="selflink" id="section-5.3.6" href="#section-5.3.6">5.3.6</a>.  QUERY Packets during Neighbor Formation</span>

   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.





<span class="grey">Savage, et al.                Informational                    [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

   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.

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  Topology Table</span>

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

   The CD is the best-advertised RD from all neighbors, plus the link
   cost between the receiving router and the neighbor.

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

   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.

<span class="h4"><a class="selflink" id="section-5.4.1" href="#section-5.4.1">5.4.1</a>.  Route Management</span>

   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.



<span class="grey">Savage, et al.                Informational                    [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h5"><a class="selflink" id="section-5.4.1.1" href="#section-5.4.1.1">5.4.1.1</a>.  Internal Routes</span>

   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.

   Internal routes are tagged with the following information:

      o Router ID of the EIGRP router that originated the route.
      o Configurable administrator tag.

<span class="h5"><a class="selflink" id="section-5.4.1.2" href="#section-5.4.1.2">5.4.1.2</a>.  External Routes</span>

   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.

   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)
   [<a href="#ref-10" title="&quot;OSPF Version 2&quot;">10</a>] and the other, BR3, also uses the Routing Information Protocol
   (RIP).

   Routes learned by one of the OSPF border routers, BR1, can be
   conditionally redistributed into EIGRP.  This means that EIGRP
   running in BR1 advertises the OSPF routes within its own AS.  When it
   does so, it advertises the route and tags it as an OSPF-learned route
   with a metric equal to the routing table metric of the OSPF route.
   The router-id is set to BR1.  The EIGRP route propagates to the other
   border routers.

   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.




<span class="grey">Savage, et al.                Informational                    [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

   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.

<span class="h4"><a class="selflink" id="section-5.4.2" href="#section-5.4.2">5.4.2</a>.  Split Horizon and Poison Reverse</span>

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

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

   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.

   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:

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

<span class="h5"><a class="selflink" id="section-5.4.2.1" href="#section-5.4.2.1">5.4.2.1</a>.  Startup Mode</span>

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







<span class="grey">Savage, et al.                Informational                    [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h5"><a class="selflink" id="section-5.4.2.2" href="#section-5.4.2.2">5.4.2.2</a>.  Advertising Topology Table Change</span>

   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.

<span class="h5"><a class="selflink" id="section-5.4.2.3" href="#section-5.4.2.3">5.4.2.3</a>.  Sending a QUERY/UPDATE</span>

   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.

   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.

<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>.  EIGRP Metric Coefficients</span>

   EIGRP allows for modification of the default composite metric
   calculation (see <a href="#section-5.6">Section 5.6</a>) 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 default coefficients have been carefully selected to provide
   optimal performance in most networks.  The default K-values are as
   follows:

               K1 == K3 == 1
               K2 == K4 == K5 == 0
               K6 == 0

   If K5 is equal to 0, then reliability quotient is defined to be 1.











<span class="grey">Savage, et al.                Informational                    [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h4"><a class="selflink" id="section-5.5.1" href="#section-5.5.1">5.5.1</a>.  Coefficients K1 and K2</span>

   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.

   o  Maximum Theoretical Bandwidth: paths chosen based on the highest
      reported bandwidth

   o  Network Throughput: paths chosen based on the highest "available"
      bandwidth adjusted by congestion-based effects (interface reported
      load)

   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.

   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.

<span class="h4"><a class="selflink" id="section-5.5.2" href="#section-5.5.2">5.5.2</a>.  Coefficient K3</span>

   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.

<span class="h4"><a class="selflink" id="section-5.5.3" href="#section-5.5.3">5.5.3</a>.  Coefficients K4 and K5</span>

   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.

   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.

   The handling of K5 is conditional.  If K5 is equal to 0, then
   reliability quotient is defined to be 1.






<span class="grey">Savage, et al.                Informational                    [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h4"><a class="selflink" id="section-5.5.4" href="#section-5.5.4">5.5.4</a>.  Coefficient K6</span>

   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.

<span class="h5"><a class="selflink" id="section-5.5.4.1" href="#section-5.5.4.1">5.5.4.1</a>.  Jitter</span>

   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.

   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.

<span class="h5"><a class="selflink" id="section-5.5.4.2" href="#section-5.5.4.2">5.5.4.2</a>.  Energy</span>

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

<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>.  EIGRP Metric Calculations</span>

<span class="h4"><a class="selflink" id="section-5.6.1" href="#section-5.6.1">5.6.1</a>.  Classic Metrics</span>

   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.

   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.





<span class="grey">Savage, et al.                Informational                    [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h5"><a class="selflink" id="section-5.6.1.1" href="#section-5.6.1.1">5.6.1.1</a>.  Classic Composite Formulation</span>

   EIGRP calculates the composite metric with the following formula:

   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.

   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.

   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:

                     (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:

                     [sum of delays]

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

             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.





<span class="grey">Savage, et al.                Informational                    [Page 42]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   The calculated EIGRP bandwidth (BW) metric is then:

               256 * (10^7)/BW = 256 * {(10^7)/10,000}
                               = 256 * 1000
                               = 256,000

   And the calculated EIGRP delay metric is then:

            256 * sum of delay = 256 * 100 * 10 microseconds
                               = 25,600 (in tens of microseconds)

<span class="h5"><a class="selflink" id="section-5.6.1.2" href="#section-5.6.1.2">5.6.1.2</a>.  Cisco Interface Delay Compatibility</span>

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

   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

<span class="h4"><a class="selflink" id="section-5.6.2" href="#section-5.6.2">5.6.2</a>.  Wide Metrics</span>

   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.




<span class="grey">Savage, et al.                Informational                    [Page 43]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h5"><a class="selflink" id="section-5.6.2.1" href="#section-5.6.2.1">5.6.2.1</a>.  Wide Metric Vectors</span>

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

              o Throughput    - Minimum value
              o Latency       - accumulative
              o Load          - maximum
              o Reliability   - minimum
              o MTU           - minimum
              o Hop count     - accumulative

   There are two additional values: Jitter and energy.  These two values
   are accumulated from destination to source:

           o Jitter - accumulative
           o Energy - accumulative

   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.

   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.

   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.

   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:



<span class="grey">Savage, et al.                Informational                    [Page 44]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-45" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


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

   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.

<span class="h5"><a class="selflink" id="section-5.6.2.2" href="#section-5.6.2.2">5.6.2.2</a>.  Wide Metric Conversion Constants</span>

   EIGRP uses a number of defined constants for conversion and
   calculation of metric values.  These numbers are provided here for
   reference

           EIGRP_BANDWIDTH                    10,000,000
           EIGRP_DELAY_PICO                    1,000,000
           EIGRP_INACCESSIBLE       0xFFFFFFFFFFFFFFFFLL
           EIGRP_MAX_HOPS                            100
           EIGRP_CLASSIC_SCALE                       256
           EIGRP_WIDE_SCALE                        65536

   When computing the metric using the above units, all capacity
   information will be normalized to kilobytes and picoseconds before
   being used.  For example, delay is expressed in microseconds per
   kilobyte, and would be converted to kilobytes per second; likewise,
   energy would be expressed in power per kilobytes per second of usage.

<span class="h5"><a class="selflink" id="section-5.6.2.3" href="#section-5.6.2.3">5.6.2.3</a>.  Throughput Calculation</span>

   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)








<span class="grey">Savage, et al.                Informational                    [Page 45]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-46" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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 * Max-Throughput
        Net-Throughput = Max-Throughput + ---------------------
                                              256 - Load

   K2 has the greatest effect on the metric occurs when the load
   increases beyond 90%.

<span class="h5"><a class="selflink" id="section-5.6.2.4" href="#section-5.6.2.4">5.6.2.4</a>.  Latency Calculation</span>

   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.

   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

<span class="h5"><a class="selflink" id="section-5.6.2.5" href="#section-5.6.2.5">5.6.2.5</a>.  Composite Calculation</span>

                                                                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:

      metric = (K1 * min(Throughput)) + (K3 * sum(Latency)) }

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  EIGRP Packet Formats</span>

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Protocol Number</span>

   The IPv6 and IPv4 protocol identifier number spaces are common and
   will both use protocol identifier 88 [<a href="#ref-8" title="&quot;Internet Protocol&quot;">8</a>] [<a href="#ref-9" title="&quot;Internet Protocol, Version 6 (IPv6) Specification&quot;">9</a>].






<span class="grey">Savage, et al.                Informational                    [Page 46]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-47" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   EIGRP IPv4 will transmit HELLO packets using either the unicast
   destination of a neighbor or using a multicast host group address [<a href="#ref-7" title="&quot;Host extensions for IP multicasting&quot;">7</a>]
   with a source address EIGRP IPv4 multicast address [<a href="#ref-13" title="&quot;IPv4 Multicast Address Space Registry&quot;">13</a>].

   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 [<a href="#ref-14" title="&quot;IPv6 Multicast Address Space Registry&quot;">14</a>].  Unicast packets directed to a specific neighbor will
   contain the destination link-local address of the neighbor.

   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.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Protocol Assignment Encoding</span>

   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:

           Protocols             Value
           IGRP                    1
           EIGRP                   2
           Static                  3
           RIP                     4
           HELLO                   5
           OSPF                    6
           ISIS                    7
           EGP                     8
           BGP                     9
           IDRP                   10
           Connected              11

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Destination Assignment Encoding</span>

   Destinations types are encoded according to the IANA address family
   number assignments.  Currently only the following types are used:

         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




<span class="grey">Savage, et al.                Informational                    [Page 47]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-48" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  EIGRP Communities Attribute</span>

   EIGRP supports communities similar to the BGP Extended Communities
   <a href="./rfc4360">RFC 4360</a> [<a href="#ref-4" title="&quot;IANA Registries for BGP Extended Communities&quot;">4</a>] 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:

          - Type field: 2 octets
          - Value field: Remaining octets

    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" [<a href="#ref-5" title="&quot;Assigning Experimental and Testing Numbers Considered Useful&quot;">5</a>] range as follows:

     Type high: 0x88
     Type low:

       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

















<span class="grey">Savage, et al.                Informational                    [Page 48]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-49" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>.  EIGRP Packet Header</span>

   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.

    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.

   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

   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.

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




<span class="grey">Savage, et al.                Informational                    [Page 49]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-50" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

   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.

   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.

   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.

   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.

   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.

   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.

             Value Range       Usage
               0x0000            Unicast Address Family
               0x0001            Multicast Address Family
               0x0002-0x7FFF     Reserved
               0x8000            Unicast Service Family
               0x8001-0xFFFF     Reserved






<span class="grey">Savage, et al.                Informational                    [Page 50]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-51" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>.  EIGRP TLV Encoding Format</span>

   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:

    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.

   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.














<span class="grey">Savage, et al.                Informational                    [Page 51]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-52" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h4"><a class="selflink" id="section-6.6.1" href="#section-6.6.1">6.6.1</a>.  Type Field Encoding</span>

   The type field is structured as follows: Type High: 1 octet that
   defines the protocol classification:

            Protocol            ID   VERSION
            General            0x00    1.2
            IPv4               0x01    1.2
            IPv6               0x04    1.2
            SAF                0x05    3.0
            Multiprotocol      0x06    2.0

   Type Low: 1 octet that defines the TLV Opcode; see TLV Definitions in
      <a href="#section-3">Section 3</a>.

<span class="h4"><a class="selflink" id="section-6.6.2" href="#section-6.6.2">6.6.2</a>.  Length Field Encoding</span>

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

<span class="h4"><a class="selflink" id="section-6.6.3" href="#section-6.6.3">6.6.3</a>.  Value Field Encoding</span>

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

<span class="h3"><a class="selflink" id="section-6.7" href="#section-6.7">6.7</a>.  EIGRP Generic TLV Definitions</span>

                                 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















<span class="grey">Savage, et al.                Informational                    [Page 52]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-53" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h4"><a class="selflink" id="section-6.7.1" href="#section-6.7.1">6.7.1</a>.  0x0001 - PARAMETER_TYPE</span>

   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.

    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:

                K1 - 1
                K2 - 0
                K3 - 1
                K4 - 0
                K5 - 0
                K6 - 0

   Hold Time: The amount of time in seconds that a receiving router
      should consider the sending neighbor valid.  A valid neighbor is
      one that is able to forward packets and participates in EIGRP.  A
      router that considers a neighbor valid will store all routing
      information advertised by the neighbor.

<span class="h4"><a class="selflink" id="section-6.7.2" href="#section-6.7.2">6.7.2</a>.  0x0002 - AUTHENTICATION_TYPE</span>

   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.

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





<span class="grey">Savage, et al.                Informational                    [Page 53]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-54" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

<span class="h5"><a class="selflink" id="section-6.7.2.1" href="#section-6.7.2.1">6.7.2.1</a>.  0x02 - MD5 Authentication Type</span>

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

<span class="h5"><a class="selflink" id="section-6.7.2.2" href="#section-6.7.2.2">6.7.2.2</a>.  0x03 - SHA2 Authentication Type</span>

   SHA2-256 Authentication will use Type code 0x03, and the Auth Data
   will be the 256-bit SHA2 [<a href="#ref-6" title="&quot;Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec&quot;">6</a>] Hash value.

<span class="h4"><a class="selflink" id="section-6.7.3" href="#section-6.7.3">6.7.3</a>.  0x0003 - SEQUENCE_TYPE</span>

   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.

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

   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.





<span class="grey">Savage, et al.                Informational                    [Page 54]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-55" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h4"><a class="selflink" id="section-6.7.4" href="#section-6.7.4">6.7.4</a>.  0x0004 - SOFTWARE_VERSION_TYPE</span>

           Field                        Length
           Vender OS major version        1
           Vender OS minor version        1
           EIGRP major revision           1
           EIGRP minor revision           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.

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

<span class="h4"><a class="selflink" id="section-6.7.5" href="#section-6.7.5">6.7.5</a>.  0x0005 - MULTICAST_SEQUENCE_TYPE</span>

   The next multicast SEQUENCE TLV.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            0x0005             |             0x0008            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Sequence Number                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<span class="h4"><a class="selflink" id="section-6.7.6" href="#section-6.7.6">6.7.6</a>.  0x0006 - PEER_INFORMATION_TYPE</span>

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















<span class="grey">Savage, et al.                Informational                    [Page 55]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-56" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h4"><a class="selflink" id="section-6.7.7" href="#section-6.7.7">6.7.7</a>.  0x0007 - PEER_ TERMINATION_TYPE</span>

   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.

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

<span class="h4"><a class="selflink" id="section-6.7.8" href="#section-6.7.8">6.7.8</a>.  0x0008 - TID_LIST_TYPE</span>

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

   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

   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.

   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.







<span class="grey">Savage, et al.                Informational                    [Page 56]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-57" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h3"><a class="selflink" id="section-6.8" href="#section-6.8">6.8</a>.  Classic Route Information TLV Types</span>

<span class="h4"><a class="selflink" id="section-6.8.1" href="#section-6.8.1">6.8.1</a>.  Classic Flag Field Encoding</span>

   EIGRP transports a number of flags with in the TLVs to indicate
   addition route state information.  These bits are defined as follows:

   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.

   ACTIVE (Bit 2) - Indicates if the route is in the ACTIVE State.

<span class="h4"><a class="selflink" id="section-6.8.2" href="#section-6.8.2">6.8.2</a>.  Classic Metric Encoding</span>

   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.

    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.

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




<span class="grey">Savage, et al.                Informational                    [Page 57]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-58" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   MTU: The minimum MTU size for the path to the destination.

   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

   Load: The load utilization of the path to the destination, measured
      as a percentage.  A value of 255 indicates 100% load.

   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.

   Flags Field: See <a href="#section-6.8.1">Section 6.8.1</a>.

<span class="h4"><a class="selflink" id="section-6.8.3" href="#section-6.8.3">6.8.3</a>.  Classic Exterior Encoding</span>

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

    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.

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

   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.




<span class="grey">Savage, et al.                Informational                    [Page 58]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-59" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

   External Protocol: Contains an enumerated value defined in <a href="#section-6.2">Section</a>
      <a href="#section-6.2">6.2</a> to identify the routing protocol (external protocol)
      redistributing the route.

   Flags Field: See <a href="#section-6.8.1">Section 6.8.1</a>

<span class="h4"><a class="selflink" id="section-6.8.4" href="#section-6.8.4">6.8.4</a>.  Classic Destination Encoding</span>

   EIGRP carries destination in a compressed form, where the number of
   bits significant in the variable-length address field are indicated
   in a counter.

    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.

   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)

<span class="h4"><a class="selflink" id="section-6.8.5" href="#section-6.8.5">6.8.5</a>.  IPv4-Specific TLVs</span>

      INTERNAL_TYPE       0x0102
      EXTERNAL_TYPE       0x0103
      COMMUNITY_TYPE      0x0104









<span class="grey">Savage, et al.                Informational                    [Page 59]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-60" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h5"><a class="selflink" id="section-6.8.5.1" href="#section-6.8.5.1">6.8.5.1</a>.  IPv4 INTERNAL_TYPE</span>

   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.

    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 <a href="#section-6.8.2">Section 6.8.2</a>)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                       Destination Section                     |
   |                 IPv4 Address (variable length)                |
   |                       (see <a href="#section-6.8.4">Section 6.8.4</a>)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

   Vector Metric Section: The vector metrics for destinations contained
      in this TLV.  See the description of "metric encoding" in <a href="#section-6.8.2">Section</a>
      <a href="#section-6.8.2">6.8.2</a>.

   Destination Section: The network/subnet/host destination address
      being requested.  See the description of "destination" in <a href="#section-6.8.4">Section</a>
      <a href="#section-6.8.4">6.8.4</a>.

<span class="h5"><a class="selflink" id="section-6.8.5.2" href="#section-6.8.5.2">6.8.5.2</a>.  IPv4 EXTERNAL_TYPE</span>

   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.








<span class="grey">Savage, et al.                Informational                    [Page 60]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-61" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


    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 <a href="#section-6.8.3">Section 6.8.3</a>)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Vector Metric Section (see <a href="#section-6.8.2">Section 6.8.2</a>)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                       Destination Section                     |
   |                 IPv4 Address (variable length)                |
   |                       (see <a href="#section-6.8.4">Section 6.8.4</a>)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

   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 <a href="#section-6.8.3">Section 6.8.3</a>.

   Vector Metric Section: Vector metrics for destinations contained in
      this TLV.  See the description of "metric encoding" in <a href="#section-6.8.2">Section</a>
      <a href="#section-6.8.2">6.8.2</a>.

   Destination Section: The network/subnet/host destination address
      being requested.  See the description of "destination" in <a href="#section-6.8.4">Section</a>
      <a href="#section-6.8.4">6.8.4</a>.


















<span class="grey">Savage, et al.                Informational                    [Page 61]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-62" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h5"><a class="selflink" id="section-6.8.5.3" href="#section-6.8.5.3">6.8.5.3</a>.  IPv4 COMMUNITY_TYPE</span>

   This TLV is used to provide community tags for specific IPv4
   destinations.

    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.

   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.

   Community List: One or more 8-octet EIGRP communities, as defined in
      <a href="#section-6.4">Section 6.4</a>.

<span class="h4"><a class="selflink" id="section-6.8.6" href="#section-6.8.6">6.8.6</a>.  IPv6-Specific TLVs</span>

      INTERNAL_TYPE                 0x0402
      EXTERNAL_TYPE                 0x0403
      COMMUNITY_TYPE                0x0404


















<span class="grey">Savage, et al.                Informational                    [Page 62]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-63" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h5"><a class="selflink" id="section-6.8.6.1" href="#section-6.8.6.1">6.8.6.1</a>.  IPv6 INTERNAL_TYPE</span>

   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.

    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 <a href="#section-6.8.2">Section 6.8.2</a>)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                       Destination Section                     |
   |                 IPv6 Address (variable length)                |
   |                       (see <a href="#section-6.8.4">Section 6.8.4</a>)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

   Vector Metric Section: Vector metrics for destinations contained in
      this TLV.  See the description of "metric encoding" in <a href="#section-6.8.2">Section</a>
      <a href="#section-6.8.2">6.8.2</a>.

   Destination Section: The network/subnet/host destination address
      being requested.  See the description of "destination" in <a href="#section-6.8.4">Section</a>
      <a href="#section-6.8.4">6.8.4</a>.

<span class="h5"><a class="selflink" id="section-6.8.6.2" href="#section-6.8.6.2">6.8.6.2</a>.  IPv6 EXTERNAL_TYPE</span>

   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.




<span class="grey">Savage, et al.                Informational                    [Page 63]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-64" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


    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 <a href="#section-6.8.3">Section 6.8.3</a>)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Vector Metric Section (see <a href="#section-6.8.2">Section 6.8.2</a>)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                        Destination Section                    |
   |                 IPv6 Address (variable length)                |
   |                       (see <a href="#section-6.8.4">Section 6.8.4</a>)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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.

   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 <a href="#section-6.8.3">Section 6.8.3</a>.

   Vector Metric Section: vector metrics for destinations contained in
      this TLV.  See the description of "metric encoding" in <a href="#section-6.8.2">Section</a>
      <a href="#section-6.8.2">6.8.2</a>.

   Destination Section: The network/subnet/host destination address
      being requested.  See the description of "destination" in <a href="#section-6.8.4">Section</a>
      <a href="#section-6.8.4">6.8.4</a>.














<span class="grey">Savage, et al.                Informational                    [Page 64]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-65" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h5"><a class="selflink" id="section-6.8.6.3" href="#section-6.8.6.3">6.8.6.3</a> IPv6 COMMUNITY_TYPE</span>

   This TLV is used to provide community tags for specific IPv4
   destinations.

    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.

   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.

   Community List: One or more 8-octet EIGRP communities, as defined in
      <a href="#section-6.4">Section 6.4</a>.





















<span class="grey">Savage, et al.                Informational                    [Page 65]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-66" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h3"><a class="selflink" id="section-6.9" href="#section-6.9">6.9</a>.  Multiprotocol Route Information TLV Types</span>

   This TLV conveys topology and associated metric information.

    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 <a href="#section-6.9.1">Section 6.9.1</a>)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Wide Metric Encoding                    |
   |                       (see <a href="#section-6.9.2">Section 6.9.2</a>)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Destination Descriptor                  |
   |                         (variable length)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<span class="h4"><a class="selflink" id="section-6.9.1" href="#section-6.9.1">6.9.1</a>.  TLV Header Encoding</span>

   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:

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




<span class="grey">Savage, et al.                Informational                    [Page 66]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-67" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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

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

<span class="h4"><a class="selflink" id="section-6.9.2" href="#section-6.9.2">6.9.2</a>.  Wide Metric Encoding</span>

   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.

    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.






<span class="grey">Savage, et al.                Informational                    [Page 67]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-68" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   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.

   Reliability: The current error rate for the path.  Measured as an
      error percentage.  A value of 255 indicates 100% reliability

   Load: The load utilization of the path to the destination, measured
      as a percentage.  A value of 255 indicates 100% load.

   MTU: The minimum MTU size for the path to the destination.  Not used
      in metric calculation but available to underlying protocols

   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.

   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.

   Reserved: Transmitted as 0x0000.

   Opaque Flags: 16-bit protocol-specific flags.  Values currently
      defined by Cisco are:

          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

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

<span class="h4"><a class="selflink" id="section-6.9.3" href="#section-6.9.3">6.9.3</a>.  Extended Metrics</span>

   Extended metrics allow for extensibility of the vector metrics in a
   manner similar to <a href="./rfc6390">RFC 6390</a> [<a href="#ref-11" title="&quot;Guidelines for Considering New Performance Metric Development&quot;">11</a>].  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.





<span class="grey">Savage, et al.                Informational                    [Page 68]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-69" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   The general formats for the Extended Metric fields are:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Opcode    |      Offset   |              Data             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Opcode: Indicates the type of Extended Metric.

   Offset: Number of 16-bit words in the application-specific
      information.  Offset does not include the length of the Opcode or
      Offset.

   Data: Zero or more octets of data as defined by Opcode.

<span class="h5"><a class="selflink" id="section-6.9.3.1" href="#section-6.9.3.1">6.9.3.1</a>.  0x00 - NoOp</span>

   This is used to pad the attribute section to ensure 32-bit alignment
   of the metric encoding section.

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

   Offset: Transmitted as zero (0) indicating no data is present.

   Data: No data is present with this attribute.

















<span class="grey">Savage, et al.                Informational                    [Page 69]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-70" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h5"><a class="selflink" id="section-6.9.3.2" href="#section-6.9.3.2">6.9.3.2</a>.  0x01 - Scaled Metric</span>

   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.

    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

   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.

   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.

<span class="h5"><a class="selflink" id="section-6.9.3.3" href="#section-6.9.3.3">6.9.3.3</a>.  0x02 - Administrator Tag</span>

   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.

    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.





<span class="grey">Savage, et al.                Informational                    [Page 70]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-71" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h5"><a class="selflink" id="section-6.9.3.4" href="#section-6.9.3.4">6.9.3.4</a>.  0x03 - Community List</span>

   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.

    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.

   Community List: One or more 8-octet EIGRP communities, as defined in
      <a href="#section-6.4">Section 6.4</a>.

<span class="h5"><a class="selflink" id="section-6.9.3.5" href="#section-6.9.3.5">6.9.3.5</a>.  0x04 - Jitter</span>

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

    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.

<span class="h5"><a class="selflink" id="section-6.9.3.6" href="#section-6.9.3.6">6.9.3.6</a>.  0x05 - Quiescent Energy</span>

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




<span class="grey">Savage, et al.                Informational                    [Page 71]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-72" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


    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.

<span class="h5"><a class="selflink" id="section-6.9.3.7" href="#section-6.9.3.7">6.9.3.7</a>.  0x06 - Energy</span>

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

    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.

<span class="h5"><a class="selflink" id="section-6.9.3.8" href="#section-6.9.3.8">6.9.3.8</a>.  0x07 - AddPath</span>

   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.

    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.




<span class="grey">Savage, et al.                Informational                    [Page 72]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-73" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   AddPath: Length of this field will vary in length based on whether it
      contains IPv4 or IPv6 data.

<span class="h6"><a class="selflink" id="section-6.9.3.8.1" href="#section-6.9.3.8.1">6.9.3.8.1</a>.  AddPath with IPv4 Next Hop</span>

    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.

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

   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 additional bytes will be
   added as follows:

   External Protocol: Contains an enumerated value defined in <a href="#section-6.2">Section</a>
      <a href="#section-6.2">6.2</a> to identify the routing protocol (external protocol)
      redistributing the route.

   Flags Field: See <a href="#section-6.8.1">Section 6.8.1</a>.














<span class="grey">Savage, et al.                Informational                    [Page 73]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-74" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h6"><a class="selflink" id="section-6.9.3.8.2" href="#section-6.9.3.8.2">6.9.3.8.2</a>.  AddPath with IPv6 Next Hop</span>

    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.

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

   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:

   External Protocol: Contains an enumerated value defined in <a href="#section-6.2">Section</a>
      <a href="#section-6.2">6.2</a> to identify the routing protocol (external protocol)
      redistributing the route.

   Flags Field: See <a href="#section-6.8.1">Section 6.8.1</a>.















<span class="grey">Savage, et al.                Informational                    [Page 74]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-75" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h4"><a class="selflink" id="section-6.9.4" href="#section-6.9.4">6.9.4</a>.  Exterior Encoding</span>

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

    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.

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

   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.

   External Protocol: Contains an enumerated value defined in <a href="#section-6.2">Section</a>
      <a href="#section-6.2">6.2</a> to identify the routing protocol (external protocol)
      redistributing the route.

   Flags Field: See <a href="#section-6.8.1">Section 6.8.1</a>.















<span class="grey">Savage, et al.                Informational                    [Page 75]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-76" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h4"><a class="selflink" id="section-6.9.5" href="#section-6.9.5">6.9.5</a>.  Destination Encoding</span>

   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.

    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.

   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)

<span class="h4"><a class="selflink" id="section-6.9.6" href="#section-6.9.6">6.9.6</a>.  Route Information</span>

<span class="h5"><a class="selflink" id="section-6.9.6.1" href="#section-6.9.6.1">6.9.6.1</a>.  INTERNAL TYPE</span>

   This TLV conveys destination information based on the IANA AFI
   defined in the TLV Header (see <a href="#section-6.9.1">Section 6.9.1</a>), 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.

<span class="h5"><a class="selflink" id="section-6.9.6.2" href="#section-6.9.6.2">6.9.6.2</a>.  EXTERNAL TYPE</span>

   This TLV conveys destination information based on the IANA AFI
   defined in the TLV Header (see <a href="#section-6.9.1">Section 6.9.1</a>), 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.





<span class="grey">Savage, et al.                Informational                    [Page 76]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-77" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Security Considerations</span>

   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 does not rely on a PKI or a heavyweight authentication system.
   These systems challenge the scalability of EIGRP, which was a primary
   design goal.

   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
   [<a href="#ref-6" title="&quot;Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec&quot;">6</a>].

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  IANA Considerations</span>

   This document serves as the sole reference for two multicast
   addresses: 224.0.0.10 for IPv4 "EIGRP Routers" [<a href="#ref-13" title="&quot;IPv4 Multicast Address Space Registry&quot;">13</a>] and
   FF02:0:0:0:0:0:0:A for IPv6 "EIGRP Routers" [<a href="#ref-14" title="&quot;IPv6 Multicast Address Space Registry&quot;">14</a>].  It also serves as
   assignment for protocol number 88 (EIGRP) [<a href="#ref-15" title="&quot;Protocol Numbers&quot;">15</a>].

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  References</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Normative References</span>

   [<a id="ref-1">1</a>]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, DOI 10.17487/RFC2119, March 1997,
        &lt;<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>&gt;.

   [<a id="ref-2">2</a>]  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 &amp;
        protocols, Volume 19, pages 212-223, ACM
        089791-332-9/89/0009/0212, DOI 10.1145/75247.75268, 1989.

   [<a id="ref-3">3</a>]  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.

   [<a id="ref-4">4</a>]  Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended
        Communities", <a href="./rfc7153">RFC 7153</a>, DOI 10.17487/RFC7153, March 2014,
        &lt;<a href="http://www.rfc-editor.org/info/rfc7153">http://www.rfc-editor.org/info/rfc7153</a>&gt;.






<span class="grey">Savage, et al.                Informational                    [Page 77]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-78" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


   [<a id="ref-5">5</a>]  Narten, T., "Assigning Experimental and Testing Numbers
        Considered Useful", <a href="https://www.rfc-editor.org/bcp/bcp82">BCP 82</a>, <a href="./rfc3692">RFC 3692</a>, DOI 10.17487/RFC3692,
        January 2004, &lt;<a href="http://www.rfc-editor.org/info/rfc3692">http://www.rfc-editor.org/info/rfc3692</a>&gt;.

   [<a id="ref-6">6</a>]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and
        HMAC-SHA-512 with IPsec", <a href="./rfc4868">RFC 4868</a>, DOI 10.17487/RFC4868, May
        2007, &lt;<a href="http://www.rfc-editor.org/info/rfc4868">http://www.rfc-editor.org/info/rfc4868</a>&gt;.

   [<a id="ref-7">7</a>]  Deering, S., "Host extensions for IP multicasting", STD 5,
        <a href="./rfc1112">RFC 1112</a>, DOI 10.17487/RFC1112, August 1989,
        &lt;<a href="http://www.rfc-editor.org/info/rfc1112">http://www.rfc-editor.org/info/rfc1112</a>&gt;.

   [<a id="ref-8">8</a>]  Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>,
        DOI 10.17487/RFC0791, September 1981,
        &lt;<a href="http://www.rfc-editor.org/info/rfc791">http://www.rfc-editor.org/info/rfc791</a>&gt;.

   [<a id="ref-9">9</a>]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
        Specification", <a href="./rfc2460">RFC 2460</a>, DOI 10.17487/RFC2460, December 1998,
        &lt;<a href="http://www.rfc-editor.org/info/rfc2460">http://www.rfc-editor.org/info/rfc2460</a>&gt;.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Informative References</span>

   [<a id="ref-10">10</a>] Moy, J., "OSPF Version 2", STD 54, <a href="./rfc2328">RFC 2328</a>,
        DOI 10.17487/RFC2328, April 1998,
        &lt;<a href="http://www.rfc-editor.org/info/rfc2328">http://www.rfc-editor.org/info/rfc2328</a>&gt;.

   [<a id="ref-11">11</a>] Clark, A. and B. Claise, "Guidelines for Considering New
        Performance Metric Development", <a href="https://www.rfc-editor.org/bcp/bcp170">BCP 170</a>, <a href="./rfc6390">RFC 6390</a>,
        DOI 10.17487/RFC6390, October 2011,
        &lt;<a href="http://www.rfc-editor.org/info/rfc6390">http://www.rfc-editor.org/info/rfc6390</a>&gt;.

   [<a id="ref-12">12</a>] IANA, "Address Family Numbers",
        &lt;<a href="http://www.iana.org/assignments/address-family-numbers">http://www.iana.org/assignments/address-family-numbers</a>&gt;.

   [<a id="ref-13">13</a>] IANA, "IPv4 Multicast Address Space Registry",
        &lt;<a href="http://www.iana.org/assignments/multicast-addresses">http://www.iana.org/assignments/multicast-addresses</a>&gt;.

   [<a id="ref-14">14</a>] IANA, "IPv6 Multicast Address Space Registry",
        &lt;<a href="http://www.iana.org/assignments/ipv6-multicast-addresses">http://www.iana.org/assignments/ipv6-multicast-addresses</a>&gt;.

   [<a id="ref-15">15</a>] IANA, "Protocol Numbers",
        &lt;<a href="http://www.iana.org/assignments/protocol-numbers">http://www.iana.org/assignments/protocol-numbers</a>&gt;.









<span class="grey">Savage, et al.                Informational                    [Page 78]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-79" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


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.

   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.

   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:

   o  Linux implementation developed by the Quagga team: Jan Janovic,
      Matej Perina, Peter Orsag, and Peter Paluch.

   o  BSD implementation developed and released by Renato Westphal.






















<span class="grey">Savage, et al.                Informational                    [Page 79]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-80" ></span>
<span class="grey"><a href="./rfc7868">RFC 7868</a>                      Cisco's EIGRP                     May 2016</span>


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

   James Ng
   Cisco Systems, Inc.
   7025 Kit Creek Rd., RTP,
   Morrisville, NC 27560
   United States
   Phone: 919-392-2582
   Email: 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

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

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

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






Savage, et al.                Informational                    [Page 80]
</pre>