tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7868

 
 
 

Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)

Part 3 of 4, p. 39 to 56
Prev RFC Part       Next RFC Part

 


prevText      Top      ToC       Page 39 
5.5.  EIGRP Metric Coefficients

   EIGRP allows for modification of the default composite metric
   calculation (see Section 5.6) through the use of coefficients (K-
   values).  This adjustment allows for per-deployment tuning of network
   behavior.  Setting K-values up to 254 scales the impact of the scalar
   metric on the final composite metric.

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

Top      Up      ToC       Page 40 
5.5.1.  Coefficients K1 and K2

   K1 is used to allow path selection to be based on the bandwidth
   available along the path.  EIGRP can use one of two variations of
   Throughput-based path selection.

   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.

5.5.2.  Coefficient K3

   K3 is used to allow delay or latency-based path selection.  Latency
   and delay are similar terms that refer to the amount of time it takes
   a bit to be transmitted to an adjacent neighbor.  EIGRP uses one-way-
   based values either provided by the interface or computed as a factor
   of the link s bandwidth.

5.5.3.  Coefficients K4 and K5

   K4 and K5 are used to allow for path selection based on link quality
   and packet loss.  Packet loss caused by network problems results in
   highly noticeable performance issues or Jitter with streaming
   technologies, voice over IP, online gaming and videoconferencing, and
   will affect all other network applications to one degree or another.

   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.

Top      Up      ToC       Page 41 
5.5.4.  Coefficient K6

   K6 has been introduced with Wide Metric support and is used to allow
   for Extended Attributes, which can be used to reflect in a higher
   aggregate metric than those having lower energy usage.  Currently
   there are two Extended Attributes, Jitter and energy, defined in the
   scope of this document.

5.5.4.1.  Jitter

   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.

5.5.4.2.  Energy

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

5.6.  EIGRP Metric Calculations

5.6.1.  Classic Metrics

   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.

Top      Up      ToC       Page 42 
5.6.1.1.  Classic Composite Formulation

   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.

Top      Up      ToC       Page 43 
   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)

5.6.1.2.  Cisco Interface Delay Compatibility

   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

5.6.2.  Wide Metrics

   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.

Top      Up      ToC       Page 44 
5.6.2.1.  Wide Metric Vectors

   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:

Top      Up      ToC       Page 45 
   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.

5.6.2.2.  Wide Metric Conversion Constants

   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.

5.6.2.3.  Throughput Calculation

   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)

Top      Up      ToC       Page 46 
   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%.

5.6.2.4.  Latency Calculation

   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

5.6.2.5.  Composite Calculation

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

6.  EIGRP Packet Formats

6.1.  Protocol Number

   The IPv6 and IPv4 protocol identifier number spaces are common and
   will both use protocol identifier 88 [8] [9].

Top      Up      ToC       Page 47 
   EIGRP IPv4 will transmit HELLO packets using either the unicast
   destination of a neighbor or using a multicast host group address [7]
   with a source address EIGRP IPv4 multicast address [13].

   EIGRP IPv6 will transmit HELLO packets with a source address being
   the link-local address of the transmitting interface.  Multicast
   HELLO packets will have a destination address of EIGRP IPv6 multicast
   address [14].  Unicast packets directed to a specific neighbor will
   contain the destination link-local address of the neighbor.

   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.

6.2.  Protocol Assignment Encoding

   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

6.3.  Destination Assignment Encoding

   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

Top      Up      ToC       Page 48 
6.4.  EIGRP Communities Attribute

   EIGRP supports communities similar to the BGP Extended Communities
   RFC 4360 [4] extended type with Type field composed of 2 octets and
   Value field composed of 6 octets.  Each Community is encoded as an
   8-octet quantity, as follows:

          - 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" [5] 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

Top      Up      ToC       Page 49 
6.5.  EIGRP Packet Header

   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.

Top      Up      ToC       Page 50 
   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

Top      Up      ToC       Page 51 
   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.

6.6.  EIGRP TLV Encoding Format

   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.

Top      Up      ToC       Page 52 
6.6.1.  Type Field Encoding

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

6.6.2.  Length Field Encoding

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

6.6.3.  Value Field Encoding

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

6.7.  EIGRP Generic TLV Definitions

                                 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

Top      Up      ToC       Page 53 
6.7.1.  0x0001 - PARAMETER_TYPE

   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.

6.7.2.  0x0002 - AUTHENTICATION_TYPE

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

Top      Up      ToC       Page 54 
   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.

6.7.2.1.  0x02 - MD5 Authentication Type

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

6.7.2.2.  0x03 - SHA2 Authentication Type

   SHA2-256 Authentication will use Type code 0x03, and the Auth Data
   will be the 256-bit SHA2 [6] Hash value.

6.7.3.  0x0003 - SEQUENCE_TYPE

   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.

Top      Up      ToC       Page 55 
6.7.4.  0x0004 - SOFTWARE_VERSION_TYPE

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

6.7.5.  0x0005 - MULTICAST_SEQUENCE_TYPE

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

6.7.6.  0x0006 - PEER_INFORMATION_TYPE

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

Top      Up      ToC       Page 56 
6.7.7.  0x0007 - PEER_ TERMINATION_TYPE

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

6.7.8.  0x0008 - TID_LIST_TYPE

   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.


Next RFC Part