RFC 7868
Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)
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.
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.
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.
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.
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.
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:
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)
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_PICO5.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].
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 116.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
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
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.
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
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.
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
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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.
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 page on part 4)
