RFC 7868
Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)
RFC 7868: Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP) 💖
- Stream: Independent Submission 🌸
- Category: Informational ✨
- Date: May 2016 📅
- ISSN: 2070-1721
- Obsoletes / Updates: this RFC doesn't list any documents it obsoletes or updates 🙅♀️
- Authors:
- D. Savage, J. Ng, and S. Moore from Cisco Systems 💅
- D. Slice from Cumulus Networks 🦋
- P. Paluch from University of Zilina 🎀
- R. White from LinkedIn 🧚
Abstract ✨
okay so this doc explains the protocol design and architecture for Enhanced Interior Gateway Routing Protocol (EIGRP) 🌈. EIGRP is a routing protocol built on Distance Vector technology 💜. The algorithm it uses is called "DUAL", which stands for Diffusing Update Algorithm, and it's referenced in "Loop-Free Routing Using Diffusing Computations" (Garcia-Luna-Aceves 1993) 📚. The algorithm and its procedures were researched, developed, and simulated by SRI International, and that's giving real academic main character energy 🎓🔥.
Status of This Memo 🌸
this one is NOT an Internet Standards Track spec, it's just published for informational purposes 🫶.
it's a contribution to the RFC Series, done independently of any other RFC stream. The RFC Editor picked to publish it at its discretion and makes no statement about its value for implementation or deployment 🤷♀️. Docs the RFC Editor approves aren't a candidate for any level of Internet Standard, see Section 2 of RFC 5741 📖.
for current status, errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7868 🔗.
Copyright Notice 💜
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Please read these carefully, bestie, because they spell out your rights and restrictions for this doc 📜.
this doc 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 🧚
1. Introduction ....................................................5
2. Conventions .....................................................5
2.1. Requirements Language ......................................5
2.2. Terminology ................................................5
3. The Diffusing Update Algorithm (DUAL) ...........................9
3.1. Algorithm Description ......................................9
3.2. Route States ..............................................10
3.3. Feasibility Condition .....................................11
3.4. DUAL Message Types ........................................13
3.5. DUAL Finite State Machine (FSM) ...........................13
3.6. DUAL Operation -- Example Topology ........................18
4. EIGRP Packets ..................................................20
4.1. UPDATE Packets ............................................21
4.2. QUERY Packets .............................................21
4.3. REPLY Packets .............................................22
4.4. Exception Handling ........................................22
4.4.1. Active Duration (SIA) ..............................22
4.4.1.1. SIA-QUERY .................................23
4.4.1.2. SIA-REPLY .................................24
5. EIGRP Operation ................................................25
5.1. Finite State Machine ......................................25
5.2. Reliable Transport Protocol ...............................25
5.2.1. Bandwidth on Low-Speed Links .......................32
5.3. Neighbor Discovery/Recovery ...............................32
5.3.1. Neighbor Hold Time .................................32
5.3.2. HELLO Packets ......................................33
5.3.3. UPDATE Packets .....................................33
5.3.4. Initialization Sequence ............................34
5.3.5. Neighbor Formation .................................35
5.3.6. QUERY Packets during Neighbor Formation ............35
5.4. Topology Table ............................................36
5.4.1. Route Management ...................................36
5.4.1.1. Internal Routes ...........................37
5.4.1.2. External Routes ...........................37
5.4.2. Split Horizon and Poison Reverse ...................38
5.4.2.1. Startup Mode ..............................38
5.4.2.2. Advertising Topology Table Change .........39
5.4.2.3. Sending a QUERY/UPDATE ....................39
5.5. EIGRP Metric Coefficients .................................39
5.5.1. Coefficients K1 and K2 .............................40
5.5.2. Coefficient K3 .....................................40
5.5.3. Coefficients K4 and K5 .............................40
5.5.4. Coefficient K6 .....................................41
5.5.4.1. Jitter ....................................41
5.5.4.2. Energy ....................................41
5.6. EIGRP Metric Calculations .................................41
5.6.1. Classic Metrics ....................................41
5.6.1.1. Classic Composite Formulation .............42
5.6.1.2. Cisco Interface Delay Compatibility .......43
5.6.2. Wide Metrics .......................................43
5.6.2.1. Wide Metric Vectors .......................44
5.6.2.2. Wide Metric Conversion Constants ..........45
5.6.2.3. Throughput Calculation ....................45
5.6.2.4. Latency Calculation .......................46
5.6.2.5. Composite Calculation .....................46
6. EIGRP Packet Formats ...........................................46
6.1. Protocol Number ...........................................46
6.2. Protocol Assignment Encoding ..............................47
6.3. Destination Assignment Encoding ...........................47
6.4. EIGRP Communities Attribute ...............................48
6.5. EIGRP Packet Header .......................................49
6.6. EIGRP TLV Encoding Format .................................51
6.6.1. Type Field Encoding ................................52
6.6.2. Length Field Encoding ..............................52
6.6.3. Value Field Encoding ...............................52
6.7. EIGRP Generic TLV Definitions .............................52
6.7.1. 0x0001 - PARAMETER_TYPE ............................53
6.7.2. 0x0002 - AUTHENTICATION_TYPE .......................53
6.7.2.1. 0x02 - MD5 Authentication Type ............54
6.7.2.2. 0x03 - SHA2 Authentication Type ...........54
6.7.3. 0x0003 - SEQUENCE_TYPE .............................54
6.7.4. 0x0004 - SOFTWARE_VERSION_TYPE .....................55
6.7.5. 0x0005 - MULTICAST_SEQUENCE_TYPE ...................55
6.7.6. 0x0006 - PEER_INFORMATION_TYPE .....................55
6.7.7. 0x0007 - PEER_ TERMINATION_TYPE ....................56
6.7.8. 0x0008 - TID_LIST_TYPE .............................56
6.8. Classic Route Information TLV Types .......................57
6.8.1. Classic Flag Field Encoding ........................57
6.8.2. Classic Metric Encoding ............................57
6.8.3. Classic Exterior Encoding ..........................58
6.8.4. Classic Destination Encoding .......................59
6.8.5. IPv4-Specific TLVs .................................59
6.8.5.1. IPv4 INTERNAL_TYPE ........................60
6.8.5.2. IPv4 EXTERNAL_TYPE ........................60
6.8.5.3. IPv4 COMMUNITY_TYPE .......................62
6.8.6. IPv6-Specific TLVs .................................62
6.8.6.1. IPv6 INTERNAL_TYPE ........................63
6.8.6.2. IPv6 EXTERNAL_TYPE ........................63
6.8.6.3. IPv6 COMMUNITY_TYPE .......................65
6.9. Multiprotocol Route Information TLV Types .................66
6.9.1. TLV Header Encoding ................................66
6.9.2. Wide Metric Encoding ...............................67
6.9.3. Extended Metrics ...................................68
6.9.3.1. 0x00 - NoOp ...............................69
6.9.3.2. 0x01 - Scaled Metric ......................70
6.9.3.3. 0x02 - Administrator Tag ..................70
6.9.3.4. 0x03 - Community List .....................71
6.9.3.5. 0x04 - Jitter .............................71
6.9.3.6. 0x05 - Quiescent Energy ...................71
6.9.3.7. 0x06 - Energy .............................72
6.9.3.8. 0x07 - AddPath ............................72
6.9.3.8.1. AddPath with IPv4 Next Hop .....73
6.9.3.8.2. AddPath with IPv6 Next Hop .....74
6.9.4. Exterior Encoding ..................................75
6.9.5. Destination Encoding ...............................76
6.9.6. Route Information ..................................76
6.9.6.1. INTERNAL TYPE .............................76
6.9.6.2. EXTERNAL TYPE .............................76
7. Security Considerations ........................................77
8. IANA Considerations ............................................77
9. References .....................................................77
9.1. Normative References ......................................77
9.2. Informative References ....................................78
Acknowledgments ...................................................79
Authors' Addresses ................................................801. Introduction ✨
okay bestie, this doc describes EIGRP, which is the Enhanced Interior Gateway Routing Protocol, a routing protocol designed and developed by Cisco Systems, Inc. 💅. DUAL is the algorithm that converges the control plane onto a single set of loop-free paths, and it's based on research done at SRI International [3] 🎓. DUAL is what gets loop freedom at every instant during a route computation [2], which is honestly iconic 🔥.
the vibe is that all the routers involved in a topology change get to synchronize at the same time 🫶. Routers that aren't affected by the topology change don't get pulled into the recalculation, so they just chill 😌🌸. This doc describes the protocol that makes all of this happen 🦋.
2. Conventions 💖
2.1. Requirements Language ✨
Okay so, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc get read exactly the way RFC 2119 [1] says 💅 Those are the official vibes, so don't freestyle them 🙈
2.2. Terminology 🎀
Here's the glossary bestie, all the terms we'll be throwing around for the rest of this doc 🧚
- ACTIVE State: The local state of a route on a router, triggered by any event that makes every neighbor providing the current least-cost path fail the Feasibility Condition check. A route in Active state is considered unusable. While in Active state, the router is actively trying to compute the least-cost loop-free path by explicitly coordinating with its neighbors using Query and Reply messages 🔥
- Address Family Identifier (AFI): Identity of the network-layer protocol reachability information being advertised [12].
- Autonomous System (AS): A collection of routers exchanging routes under the control of one or more network administrators on behalf of a single administrative entity.
- Base Topology: A routing domain showing a physical (non-virtual) view of the network topology, made up of attached devices and network segments that 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): The total distance (metric) along a path from the current router to a destination network through a particular neighbor. It's computed from that neighbor's Reported Distance (RD) plus 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 where a single starting node kicks things off by handing subtasks to its neighbors, who can then recursively hand sub-subtasks further along. It includes a signaling scheme that lets the starting node know when the computation is finished, without falsely terminating early 🦋 In DUAL, coordinated updates of routing tables and the resulting best path computation are done as a diffusing computation.
- Diffusing Update Algorithm (DUAL): A loop-free routing algorithm used with distance vectors or link states that gives a diffused computation of a routing table. It works super well with multiple topology changes and low overhead 👑 The technology was researched and developed at SRI International [3].
- Downstream Router: A router that's one or more hops away from the router in question, in the direction of the destination.
- EIGRP: Enhanced Interior Gateway Routing Protocol.
- Feasibility Condition: A sufficient condition a router uses to check whether a neighboring router provides a loop-free path to a destination. EIGRP uses the Source Node Condition, which says a neighbor meets the Feasibility Condition if the neighbor's RD is less than this router's Feasible Distance 💀
- Feasible Distance (FD): The least-known total metric to a destination from the current router since the last transition from ACTIVE to PASSIVE state. The FD is basically a record of the smallest known metric since the network last entered PASSIVE state, so it isn't necessarily the 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, which means it provides a guaranteed loop-free path ✨
- Neighbor/Peer: For a particular router, another router that it establishes an EIGRP session with, also known as an "adjacency". Whether two routers can become neighbors depends on their mutual connectivity and on whether their selected EIGRP configuration parameters are compatible. Two neighbors with interfaces on a common subnet are called adjacent neighbors. Two neighbors that are multiple hops apart are called remote neighbors 🌈
- PASSIVE state: The local state of a route where at least one neighbor providing the current least-cost path passes the Feasibility Condition check. A route in PASSIVE state is considered usable and doesn't need a coordinated re-computation 💖
- Network Layer Reachability Information (NLRI): Information a router uses to calculate the global routing table so it can 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 isn't the same as the router's current distance to the destination, and the two can differ during path re-computation. Exactly one RD is computed and maintained per destination network 💅
- Sub-Topology: For a given Base Topology, a sub-topology is an independent set of routers and links in a network where EIGRP runs an independent path calculation. This lets each sub-topology implement class-specific topologies to carry class-specific traffic 🦋
- 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 stayed in the ACTIVE State for longer than a predefined time period at the local router (Cisco implements this as 3 minutes). Ngl this is a major vibe check 😭
- Successor-Directed Acyclic Graph (SDAG): For a particular destination, a graph defined by the routing table contents of the individual routers in the topology. The graph's nodes are the routers themselves, and there's a directed edge from router X to router Y if and only if router Y is router X's successor. Once the network has converged, with no 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. For example, detecting a link-cost change, or receiving any EIGRP message from a neighbor advertising an updated neighbor's RD ⭐
- Topology Identifier (TID): A number used to mark prefixes as belonging to a specific sub-topology 🎀
- Topology Table: A data structure EIGRP uses to store information about every known destination, including (but not limited to) the network prefix / prefix length, the FD, the RD of each neighbor advertising the destination, the CD over the corresponding neighbor, and the route state 🧚
- Type, Length, Value (TLV): An encoding format for information elements used in EIGRP messages to exchange information. Each TLV-formatted information element has three generic fields: Type, which identifies the nature of the information in the element; Length, which describes the length of the entire TLV triplet; and Value, which carries the actual information. The Value field can itself be internally structured, depending on the type of information element. This format allows for extensibility and backward compatibility, which is literally so smart 🧠✨
- Upstream Router: A router that's one or more hops away from the router in question, in the direction of the source of the information 🌸
- 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 💜
3. The Diffusing Update Algorithm (DUAL) ✨
The Diffusing Update Algorithm (DUAL) builds least-cost paths to all reachable destinations in a network made of nodes and edges (routers and links). DUAL guarantees that each constructed path stays loop free at every instant, including during topology changes and network reconvergence 🔥 It works because every router affected by a topology change works out the new best path in a coordinated (diffusing) way, and uses the Feasibility Condition to check prospective paths for loop freedom. Routers that aren't affected by the topology change don't get involved in the recalculation at all. The convergence time with DUAL rivals that of any other existing routing protocol 👑
3.1. Algorithm Description 🦋
DUAL is what lets EIGRP converge fast and loop-free with very little overhead. That means EIGRP can hit convergence rates comparable to, and in some cases better than, most common link state protocols [10] 💅 Only the nodes affected by a topology change need to pass along and act on information about that change. So EIGRP scales well, has reduced overhead, and is less complicated than lots of other interior gateway protocols 🌈
Distributed routing algorithms have to propagate information and also coordinate it among all the nodes in the network. Basic Bellman-Ford distance vector protocols just rely on uncoordinated updates when a topology change happens. DUAL is different: it uses a coordinated procedure to pull the affected part of the network into computing a new least-cost path, which is called a "diffusing computation" 🧚 A diffusing computation grows as it queries additional routers for their current RD to the affected destination, and it shrinks as replies come back. Unaffected routers send replies right away, which ends the growth of the diffusing computation over them. These built-in properties make the diffusing computation self-adjust in scope and wrap up as soon as possible 🫶
One big feature of DUAL is that it can control the point where the diffusion of a route calculation ends, by managing how reachability information gets spread through the network 💖
Controlling the scope of the diffusing process happens by hiding reachability information through aggregation (summarization), filtering, or other means. This creates effective failure domains within a single AS, and lets the network administrator manage the convergence and processing characteristics of the network 🎀
3.2. Route States 💖
okay so a route to a destination can be in one of two states: PASSIVE or ACTIVE 🦋. these states tell you whether the route is guaranteed to be both loop free and the shortest available (that's PASSIVE), or whether that guarantee can't be given (that's ACTIVE). so 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 with its neighbors 🔥. the state gets 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 like this:
- 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 🍓.
- Active: a route is considered to be in the ACTIVE state if neighbors that do not pass the Feasibility Condition check provide the lowest-cost path, so 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 💜.
and the flip side: 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, and it needs 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 might feel kinda unintuitive, ngl 💀. but it can happen during topology changes, when the current least-total-cost path fails and the next-least-total-cost path goes through a neighbor that is not a Feasible Successor.
while a router has a route in the ACTIVE state, it must not change its successor (i.e., modify the current SDAG) nor modify its own Feasible Distance or RD until the route enters the PASSIVE state again. any updated information about this route received during ACTIVE state is reflected only in CDs. any updates to the successor, FD, and RD are postponed until the route returns to PASSIVE state. the state transitions from PASSIVE to ACTIVE and from ACTIVE to PASSIVE are controlled by the DUAL FSM and are described in detail in Section 3.5 🎀.
3.3. Feasibility Condition 🌸
the Feasibility Condition is a criterion used to verify loop freedom of a particular path 🔍. it's a sufficient but not a necessary condition, which means every path meeting the Feasibility Condition is guaranteed to be loop free 💅. however, not all loop-free paths meet the Feasibility Condition, so don't get it twisted 🙃.
the Feasibility Condition is used as an integral part of DUAL operation: every path selection in DUAL is subject to the Feasibility Condition check 🔥. after a topology change is detected, the result of that check decides the route's fate. the route may either remain PASSIVE (if, after the topology change, the neighbor providing the least-cost path still meets the Feasibility Condition), or it needs to enter the ACTIVE state (if the topology change left none of the neighbors providing the least-cost path meeting the Feasibility Condition) 🦋.
the Feasibility Condition is the part of DUAL that lets the diffused computation terminate as early as possible ⭐. nodes that aren't affected by the topology change don't have to perform a DUAL computation, and they may not even be aware that a topology change occurred 🫧. this can happen in two cases:
first, if informed about a topology change, a router may keep a route in PASSIVE state if it is aware of other paths that are downstream towards the destination (routes meeting the Feasibility Condition) 🌈. a route that meets the Feasibility Condition is determined to be loop free and downstream along the path between the router and the destination 🍓.
second, if informed about a topology change for which it does not currently have reachability information, a router is not required to enter the ACTIVE state, and it is not required to participate in the DUAL process either 🧚.
okay, so to make the Feasibility Condition easier to talk about, here are a few definitions 📝:
- successor: for a given route, this 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 💖.
- Feasible Successor: a neighbor that meets the Feasibility Condition 🫶. a Feasible Successor is regarded as a downstream neighbor towards the destination. it may not be on the least-cost path, but it could still be used for forwarding data packets if equal or unequal cost load sharing was active 🍰. a Feasible Successor can become a successor when the current successor becomes unreachable 👑.
- Feasibility Condition: it's met when a neighbor's advertised cost (RD) to a destination is less than the FD for that destination. 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 last entered the PASSIVE state 🎯.
- FD: the lowest distance to the destination since the last time the route went from ACTIVE to PASSIVE state 🕰️. it's not necessarily the current best distance. it's more like a historical record of the best distance known since the last diffusing computation for the destination finished 📜. so 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, so it can't be guaranteed to be the next hop for a loop-free path 🙅♀️. routes advertised by upstream neighbors aren't recorded in the routing table. they get saved in the topology table instead 🗂️.
3.4. DUAL Message Types 💌
DUAL operates with three basic message types: QUERY, UPDATE, and REPLY 📨.
- UPDATE: sent to indicate a change in metric or an addition of a destination 🆙.
- 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 😱.
- REPLY: sent in response to a QUERY or SIA-QUERY 🙋♀️.
in addition to these three basic types, EIGRP has two more sub-types 🎁:
- SIA-QUERY: sent when a REPLY has not been received within one-half of the SIA interval (90 seconds as implemented by Cisco) ⏰.
- 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's only used to show 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 💜.
3.5. DUAL Finite State Machine (FSM) ✨
Okay so the DUAL FSM is basically the brain 🧠 of all the route decisions! It keeps track of every route that every neighbor advertises. DUAL uses the metric (the distance info) to pick efficient loop-free paths 🦋. It picks which routes go into the routing table based on Feasible Successors. A successor is a neighboring router that does the packet forwarding and has a least-cost path to a destination that is guaranteed not to be part of a routing loop. Iconic behavior, honestly 💅.
When there are no Feasible Successors but neighbors are still advertising the destination, a recalculation has to happen to find a new successor 😬.
Recalculation time affects how fast convergence happens. Even though recalculation isn't super processor-heavy, it's still smart to skip it when you don't need it 🌸. So when a topology change happens, DUAL checks for Feasible Successors first. If it finds any, it uses them so it doesn't do any unnecessary recalculation. Main character energy 👑.
The FSM runs per destination in the topology table, so each destination gets its own independent FSM 🧚. It's totally true that if one link goes down, multiple routes can go into ACTIVE state at once 💀. But a separate SDAG is computed for each destination, so loop-free topologies can be kept up for every reachable destination 💖.
+------------+ +-----------+
| \ / |
| \ / |
| +=================================+ |
| | | |
|(1)| Passive |(2)|
+-->| |<--+
+=================================+
^ | ^ ^ ^ |
(14)| |(15)| |(13)| |
| (4)| |(16)| | (3)|
| | | | | +------------+
| | | | | \
+-------+ + + | +-------------+ \
/ / / | \ \
/ / / +----+ \ \
| | | | | |
| v | | | v
+==========+(11) +==========+ +==========+(12) +==========+
| Active |---->| Active |(5) | Active |---->| Active |
| | (9)| |---->| | (10)| |
| oij=0 |<----| oij=1 | | oij=2 |<----| oij=3 |
+--| | +--| | +--| | +--| |
| +==========+ | +==========+ | +==========+ | +==========+
| ^ |(5) | ^ | ^ ^ | ^
| | +-----|------|---------|----+ | | |
+------+ +------+ +---------+ +---------+
(6,7,8) (6,7,8) (6,7,8) (6,7,8)Figure 1: DUAL Finite State Machine
The legend is below, so you can decode the art 🔍:
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 kHere's the play-by-play of the state/event/action transitions of the DUAL FSM 🎀. For every step, the topology table gets updated with the new metric info from whichever QUERY, REPLY, or UPDATE came in.
(1) Okay so a QUERY comes in from a neighbor that is not the current successor 🙅♀️. The route is chilling in PASSIVE state. The successor isn't affected by the QUERY, and there's a Feasible Successor, so the route stays PASSIVE. Since a Feasible Successor exists, a REPLY MUST be sent back to whoever sent the QUERY 📨. Any metric from that neighbor gets recorded in the topology table, and then the Feasibility Check (FC) runs to see if the current successor needs to change.
(2) Lowkey this one is about changes. A directly connected interface changes state (it connects, disconnects, or changes its metric). Or an UPDATE or QUERY comes in with a metric change for a destination that already exists 🔄. The route stays in PASSIVE state if the current successor isn't affected by the change, or if the successor is no longer reachable and there's a Feasible Successor. Either way, an UPDATE gets sent with the new metric info if it changed ✨.
(3) A QUERY comes in from a neighbor who IS the current successor, and there are no Feasible Successors 😭. 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 kicks in for a query or update from the successor the router is using for the destination in that query 🙈. The QUERY origin flag gets set to show the QUERY came from a neighbor marked as the successor for the route. The REPLY status flag gets set for all neighbors to show that replies are still outstanding.
(4) A directly connected link has gone down, its cost went up, or an UPDATE came in with a metric increase 💥. The route to the destination goes to ACTIVE state if no Feasible Successors are found. A QUERY is sent to all neighbors on all interfaces. The QUERY origin flag shows that the router itself originated the QUERY. The REPLY status flag is set to 1 for all neighbors to show replies are outstanding.
(5) While a route for a destination is in ACTIVE state, and a QUERY comes in from the current successor, the route stays in ACTIVE state 🫶. The QUERY origin flag gets set to show that there was another topology change while in ACTIVE state. This is the part that makes sure new Feasible Successors get compared to the metric that sent the route into ACTIVE state, with the current successor.
(6) While a route for a destination is in ACTIVE state and a QUERY comes in from a neighbor that is not the current successor, a REPLY should be sent to that neighbor 💜. The metric from the QUERY should be recorded.
(7) If a link cost changes, or an UPDATE with a metric change comes in while in ACTIVE state from a non-successor, the router stays in ACTIVE state for the destination 🌈. The metric info in the UPDATE gets recorded. When a route is in the ACTIVE state, neither a QUERY nor an UPDATE is ever sent. Never. Not once 🙅♀️.
(8) If a REPLY for a destination comes in while in ACTIVE state from a neighbor, or the link between the router and the neighbor fails, the router records that the neighbor replied to the QUERY 🙌. The REPLY status flag is set to 0 to show this. The route stays in ACTIVE state if there are more replies pending, because the router still hasn't heard from every neighbor.
(9) If a route for a destination is in ACTIVE state, and a link fails or a cost increase happens between the router and its successor, the router treats it like it got a REPLY from its successor 🧃. When this happens after the router originates a QUERY, it sets the QUERY origin flag to show that another topology change happened in ACTIVE state.
(10) Same vibe as (9), but this time a link fails or a cost goes up between the router and its successor, and the treatment is again like a REPLY from the successor 💅. When this happens after a successor originated a QUERY, the router sets the QUERY origin flag to show that another topology change happened in ACTIVE state.
(11) If a route for a destination is in ACTIVE state, the cost of the link through which the successor increases, the last REPLY came in from all neighbors, and there's still 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.
(12) If a route for a destination is in ACTIVE state because of a QUERY from the current successor, and the last REPLY came in from all neighbors but there's still 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) Replies came in from all neighbors. Since the QUERY origin flag says the successor originated the QUERY, the route transitions to PASSIVE state and sends a REPLY to the old successor 🦋.
(14) Replies came in from all neighbors. Since the QUERY origin flag shows a topology change to the successor happened while in ACTIVE state, the router doesn't need to send a REPLY to the old successor 🙃. When the Feasibility Condition is met, the route state transitions to PASSIVE.
(15) Replies came in from all neighbors. The QUERY origin flag shows either that the router itself originated the QUERY, or that FC wasn't satisfied with the replies received in ACTIVE state 🫠. So FD gets reset to an infinite value, the minimum of all the reported metrics is picked as the new FD, and the route transitions back to PASSIVE state. A REPLY is sent to the old successor if the oij flags show there was a QUERY from the successor.
(16) If a route for a destination is in ACTIVE state because of a QUERY from the current successor, or because there was a distance increase while in ACTIVE state, and the last REPLY came in from all neighbors and a Feasible Successor exists for the destination ✨, the route can go into PASSIVE state. A REPLY is sent to the successor if the oij flags show the QUERY came from the successor.
3.6. DUAL Operation -- Example Topology ✨
okay bestie, let's walk through an example topology 🗺️ that shows how DUAL reroutes after a link goes down. Each node is labeled with its costs to destination N, the arrows show the successor (next hop) used to reach N, and the least-cost path is the one that gets picked 💅
Figure 2 is the stable topology before anything breaks:
N
|
(1)A ---<--- B(2)
| |
^ |
| |
(2)D ---<--- C(3)Figure 2: Stable Topology
Now the link between A and D fails (Figure 3) 💔
N N
| |
A ---<--- B A ---<--- B
| | | |
X | ^ |
| | | |
D ---<--- C D ---<--- C
Q-> <-R
N
|
(1)A ---<--- B(2)
|
^
|
(4)D --->--- C(3)Figure 3: Link between A and D Fails
So, only looking at the destination from node N, D goes into the ACTIVE state 🚨 and sends a QUERY to all its neighbors. In this case that's just node C.
C figures out it has a Feasible Successor, so it replies right away with metric 3 🙌
C swaps its old successor for D with its new single successor B. The route to N stays in PASSIVE state, so no drama there ✨
D gets the REPLY and can leave ACTIVE state, since replies came back from all of its neighbors 🎉
D now has a viable path to N through C, and it picks C as its successor to reach N with a cost of 4 💖
Notice that nodes A and B never got involved in the recalc 🫶 they weren't affected by the change, so they just chilled.
Now let's look at Figure 4, where Feasible Successors might not exist 👀 If the link between node A and B fails, B goes into ACTIVE state for destination N because it has no Feasible Successors. B sends a QUERY to node C.
C has no Feasible Successors either, so it goes active for destination N too 😭 And since C has no neighbors, it replies to the QUERY, deletes the destination, and goes back to PASSIVE for the unreachable route. Once C removes the (now unreachable) destination from its table, it sends a REPLY to its old successor.
B gets this REPLY from C and figures out it's the last REPLY it was waiting on before it decides what the route's new state should be. Once that REPLY lands, B deletes the route to N from its routing table 🥀
Since B was the originator of the initial QUERY, it doesn't have to send a REPLY to its old successor. (It wouldn't be able to anyway, because the link to its old successor is down.) Also, nodes A and D weren't involved in the recalc, since their successors weren't affected 🌸
N N
| |
(1)A ---<--- B(2) A ------- B Q
| | | | |^ ^
^ ^ ^ | v| |
| | | | | |
(2)D C(3) D C ACK RFigure 4: No Feasible Successors When Link between A and B Fails
4. EIGRP Packets 📦
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 PacketsEIGRP packets are directly encapsulated into a network-layer protocol, like IPv4 or IPv6 🌈 EIGRP can use extra encapsulation (like AppleTalk, IPX, etc.), but this document doesn't specify any further encapsulation.
Fragmentation at the network layer is not supported 🙅♀️ so EIGRP will try 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 instead.
Every 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 are used:
224.0.0.10for IPv4 "EIGRP Routers" [13]FF02:0:0:0:0:0:0:Afor IPv6 "EIGRP Routers" [14]
They'll be used on multicast-capable media, and they're media independent for unicast addresses. Network-layer addresses get used, and the mapping to media addresses is handled by the native protocol mechanisms 🧚
4.1. UPDATE Packets 💌
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 that new neighbor, so the neighbor can build up its topology table 🏗️ In normal operation (other than neighbor startup, like link cost changes), UPDATE packets are multicast. UPDATE packets are always transmitted reliably 💯 Each TLV destination gets processed individually through the DUAL FSM.
4.2. QUERY Packets 🔍
A QUERY packet carries the DUAL QUERY message type. A router sends it to advertise that a route is in ACTIVE state and that 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 a topology change 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 doesn't need to 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.
When a QUERY packet is received, each destination triggers a DUAL event, and the state machine runs individually for each route. Once the entire original QUERY packet is processed, a REPLY or SIA-REPLY gets sent with the latest information 📬
4.3. REPLY Packets 💬
A REPLY packet carries the DUAL REPLY message type and gets sent in response to a QUERY or SIA-QUERY packet. The REPLY packet includes 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's no reason to process the packet before an acknowledgment is sent 🙃 So an acknowledgment goes out immediately, and then the packet gets processed. The acknowledgment is sent either by sending an ACK packet or by piggybacking the acknowledgment onto another packet that's already being transmitted.
Each TLV destination gets 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 is added to the topology table with the metric in the QUERY, as long as that metric isn't an infinite value.
If a REPLY comes in for a designation that's not in the Active state, or that isn't in the topology table, EIGRP will acknowledge the packet and discard the REPLY 🗑️
4.4. Exception Handling 🚑
4.4.1. Active Duration (SIA) ⏳
When an EIGRP router transitions to ACTIVE state for a particular destination, a QUERY is sent to a neighbor and the ACTIVE timer starts. This limits how long a destination can stay in an ACTIVE state ⏱️
A route is regarded as SIA when it doesn't receive a REPLY within a preset time. That time interval is broken into two equal periods following the QUERY, plus up to three additional "busy" periods in which an SIA-QUERY packet is sent for the destination.
This process begins when a router sends a QUERY to its neighbor. After one-half the SIA time interval (default implementation is 90 seconds), the router sends an SIA-QUERY, which must be replied to with either a REPLY or SIA-REPLY. Any neighbor that fails to send either a REPLY or SIA-REPLY with-in one-half the SIA interval gets 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 still in an ACTIVE state (as noted in the SIA-Reply message), the neighbor is 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). 🫶
4.4.1.1. SIA-QUERY 🎀
okay so, when a QUERY is still outstanding and waiting on a REPLY from a neighbor, the router genuinely can't tell why the REPLY hasn't shown up 😭 it could be a lost packet, congestion on the link, or just a slow neighbor. no way to know yet, bestie.
so to figure out if the neighbor is still trying to converge on the active route, EIGRP may send an SIA-QUERY packet to the active neighbor(s) 🦋 this lets an EIGRP router check whether there's an actual communication problem with the neighbor, or if they're just still busy converging with their downstream routers. main character energy of checking in ✨
by sending an SIA-QUERY, the originating router can extend the effective active time by resetting the ACTIVE timer that was already set. so convergence keeps going for as long as the neighbors keep successfully saying "hey, we're still working on it" 💅
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 🌸
when an EIGRP router gets an SIA-QUERY, it should first send an ACK and then keep processing the SIA-QUERY information. the QUERY is sent on a per-destination basis at approximately one-half the active time, so the timing is basically the same vibe 🧚
if the EIGRP router is still active for the destination named in the SIA-QUERY, it should reply to the originator with an SIA-REPLY. that reply says active processing for this destination is still underway, and it does that by setting the ACTIVE flag in the packet 🔥
now the tricky one 👀 if the router gets an SIA-QUERY about a destination it never got the original QUERY for, the router should treat that packet like a standard QUERY:
- Acknowledge the receipt of the packet
- Send a REPLY if a successor exists
- 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
4.4.1.2. SIA-REPLY 🍓
an SIA-REPLY packet is the response you send back when you receive an SIA-QUERY from an EIGRP neighbor 💖 it includes a TLV for each destination along with the associated vector metric in the topology table. and it only goes out after the entire received SIA-QUERY has been processed, so no rushing 🙈
if the EIGRP router is still ACTIVE for a destination, the SIA-REPLY gets sent with the ACTIVE bit set. this is basically a receipt for the neighbor saying "yep, DUAL processed your SIA-QUERY, and I'm still trying to figure out a loop-free path" (probably waiting on replies to its own QUERIES to downstream neighbors) 🫶
the SIA-REPLY tells the other side whether convergence is finished or still going. it's an explicit "I'm still actively in the convergence process" message 💅 and that's what lets the device that sent the SIA-QUERY decide whether to keep letting the not-yet-converged routes sit in the ACTIVE state, or whether to reset the neighbor relationship and flush all routes through that neighbor 💀
5. EIGRP Operation ✨
EIGRP has four basic components, and honestly they're all iconic 👑
- Finite State Machine
- Reliable Transport Protocol
- Neighbor Discovery/Recovery
- Route Management
5.1. Finite State Machine 🦋
the detail of DUAL, the State Machine that EIGRP uses, is covered in Section 3.5. go read that one, it's the star of the show 🌟
5.2. Reliable Transport Protocol 💜
the reliable transport handles guaranteed, ordered delivery of EIGRP packets to all neighbors 🎀 it supports a mix of multicast and unicast packets being sent together. some EIGRP packets must be sent reliably and others don't have to be. for efficiency, reliability only gets switched on when it's actually necessary, which is very much a "don't do extra work" energy 💅
for example, on a multi-access network with multicast capabilities (think Ethernet), HELLOs don't need to be sent reliably to every neighbor one by one. EIGRP sends a single multicast HELLO and marks it in the packet so the receivers know they don't need to acknowledge it 🦋 other packets, like UPDATE packets, do need acknowledgment, and the packet says so too. the reliable transport also has a way to send multicast packets quickly when there are unacknowledged packets pending. this keeps convergence time low even when links are different speeds ⚡
DUAL assumes communication between devices is lossless, so it has to depend on the transport protocol to guarantee that messages get sent reliably 🫶 EIGRP implements the reliable transport protocol so messages get delivered in order and acknowledged whenever reliable transmission is needed. state such as the received sequence number, the acknowledgment number, and the transmission queues MUST be maintained on a per-neighbor basis 🌈
the following sequence number rules must be met for the EIGRP reliable transport protocol to work correctly 🔥
- 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 receiver's sequence number in the acknowledgment number field of the fixed header.
- Any packets that do not require acknowledgment must be sent with a sequence number of 0.
- Any packet that has an acknowledgment number of 0 indicates that the sender is not expecting to explicitly acknowledge delivery. Otherwise, it is acknowledging a single packet.
- Packets that are network-layer multicast must contain an 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 the packet is sent out on 🍓 when individual acknowledgments come back as unicast from the receivers to the sender, with the acknowledgment number matching the packet's sequence number, the sender SHALL clear the pending acknowledgment requirement for that packet from the respective neighbor ✨
if the required acknowledgment never shows up, the packet MUST be retransmitted 😭 retransmissions happen for a maximum of 5 seconds. each packet's retransmission is tried 16 times, and after that, if there's still no ACK, the neighbor relationship gets reset with the peer that didn't send the ACK. rip 💀
the protocol has no explicit windowing support. a receiver acknowledges each packet individually and drops packets that show up out of order 🧚
Implementation note: the exception to this is when a duplicate packet arrives and the acknowledgment for the original packet has been scheduled but not yet sent. in that case EIGRP won't send an acknowledgment for the duplicate packet, and the queued acknowledgment will cover both the original and the duplicate packet. 🙈
duplicate packets get discarded on receipt too 💅 acknowledgments are not accumulative, so an ACK with a non-zero sequence number acknowledges a single packet, and only that one 🫶
there are situations where multicast and unicast packets get transmitted close together on multi-access broadcast-capable networks. the reliable transport mechanism MUST ensure that all multicasts are transmitted in order, and that the order isn't mixed up between unicast and multicast packets 🎀 the reliable transport also provides a mechanism to deliver multicast packets quickly to some receivers, even while other receivers haven't yet gotten all their unicast packets or earlier multicast packets. the SEQUENCE_TYPE TLV in HELLO packets is what makes this happen 🌸 we'll go through it in more detail in this section 💖
Figure 5 illustrates the reliable transport protocol on point-to-point links. there are two scenarios that can happen: an UPDATE-initiated packet exchange or a QUERY-initiated packet exchange 🦋
this example assumes no packet loss 🌷
Router A Router B
An Example UPDATE Exchange
<----------------
UPDATE (multicast)
A receives packet SEQ=100, ACK=0
Add packet to A's retransmit list
---------------->
ACK (unicast)
SEQ=0, ACK=100 Receive ACK
Process UPDATE Delete packet from A's retransmit list
An Example QUERY Exchange
<----------------
QUERY (multicast)
A receives packet SEQ=101, ACK=0
Process QUERY Add packet to A's retransmit list
---------------->
REPLY (unicast)
SEQ=201, ACK=101 Process ACK
Delete packet from A's retransmit
list
Process REPLY packet
<----------------
ACK (unicast)
A receives packet SEQ=0, ACK=201Figure 5: Reliable Transfer on Point-to-Point Links
the UPDATE exchange sequence requires that UPDATE packets sent get delivered reliably 🔥 the UPDATE packet carries a sequence number that gets acknowledged when an ACK packet comes back. if the UPDATE or the ACK packet gets lost on the network, the UPDATE packet gets retransmitted 😭
this example assumes there is heavy packet loss on a network 💀
Router A Router B
<----------------
UPDATE (multicast)
A receives packet SEQ=100, ACK=0
Add packet to A's retransmit list
---------------->
ACK (unicast)
SEQ=0, ACK=100 Receive ACK
Process UPDATE Delete packet from A's retransmit list
<--/LOST/--------------
UPDATE (multicast)
SEQ=101, ACK=0
Add packet to A's retransmit list
Retransmit Timer Expires
<----------------
Retransmit UPDATE (unicast)
SEQ=101, ACK=0
Keep packet on A's retransmit list
---------------->ACK (unicast)
SEQ=0, ACK=101 Receive ACK
Process UPDATE Delete packet from A's retransmit list
Figure 6: Reliable Transfer on Lossy Point-to-Point LinksOkay so reliable delivery on multi-access LANs works kind of like point-to-point links, but with a few twists 💅 The first packet is always multicast, and any retransmissions after that are unicast addressed. The acknowledgments are always unicast addressed too. Figure 7 shows an example with four routers on an Ethernet 🌸
Router B -----------+
|
Router C -----------+------------ Router A
|
Router D -----------+
An Example UPDATE Exchange
<----------------
A send UPDATE (multicast)
SEQ=100, ACK=0
Add packet to B's retransmit list
Add packet to C's retransmit list
Add packet to D's retransmit list
---------------->
B sends ACK (unicast)
SEQ=0, ACK=100 Receive ACK
Process UPDATE Delete packet from B's retransmit list
---------------->
C sends ACK (unicast)
SEQ=0, ACK=100 Receive ACK
Process UPDATE Delete packet from C's retransmit list
---------------->
D sends ACK (unicast)
SEQ=0, ACK=100 Receive ACK
Process UPDATE Delete packet from D's retransmit list
An Example QUERY Exchange
<----------------
A sends UPDATE (multicast)
SEQ=101, ACK=0
Add packet to B's retransmit list
Add packet to C's retransmit list
Add packet to D's retransmit list
---------------->
B sends REPLY (unicast) <----------------
SEQ=511, ACK=101 A sends ACK (unicast to B)
Process UPDATE SEQ=0, ACK=511
Delete packet from B's retransmit list
---------------->
C sends REPLY (unicast) <----------------
SEQ=200, ACK=101 A sends ACK (unicast to C)
Process UPDATE SEQ=0, ACK=200
Delete packet from C's retransmit list
---------------->
D sends REPLY (unicast) <----------------
SEQ=11, ACK=101 A sends ACK (unicast to D)
Process UPDATE SEQ=0, ACK=11
Delete packet from D's retransmit list
Figure 7: Reliable Transfer on Multi-Access LinksAnd last but absolutely not least 🫶 is a situation where a bunch of multicast and unicast packets get sent close together in a multi-access environment. That's shown in Figure 8 💀
Router B -----------+
|
Router C -----------+------------ Router A
|
Router D -----------+
<----------------
A sends UPDATE (multicast)
SEQ=100, ACK=0
---------------/LOST/-> Add packet to B's retransmit list
B sends ACK (unicast) Add packet to C's retransmit list
SEQ=0, ACK=100 Add packet to D's retransmit list
---------------->
C sends ACK (unicast)
SEQ=0, ACK=100 Delete packet from C's retransmit list
---------------->
D sends ACK (unicast)
SEQ=0, ACK=100 Delete packet from D's retransmit list
<----------------
A sends HELLO (multicast)
SEQ=0, ACK=0, SEQ_TLV listing B
B receives Hello, does not set CR-Mode
C receives Hello, sets CR-Mode
D receives Hello, sets CR-Mode
<----------------
A sends UPDATE (multicast)
SEQ=101, ACK=0, CR-Flag=1
---------------/LOST/-> Add packet to B's retransmit list
B sends ACK (unicast) Add packet to C's retransmit list
SEQ=0, ACK=100 Add packet to D's retransmit list
B ignores UPDATE 101 because the CR-Flag
is set and it is not in CR-Mode
---------------->
C sends ACK (unicast)
SEQ=0, ACK=101
---------------->
D sends ACK (unicast)
SEQ=0, ACK=101
<----------------
A resends UPDATE (unicast to B)
SEQ=100, ACK=0
B packet duplicate
--------------->
B sends ACK (unicast) A removes packet from retransmit list
SEQ=0, ACK=100
<----------------
A resends UPDATE (unicast to B)
SEQ=101, ACK=0
--------------->
B sends ACK (unicast) A removes packet from retransmit list
SEQ=0, ACK=101
Figure 8: Reliable Transfer on Multi-Access Links
with Conditional ReceiveSo here's the story 📖 Router A starts by sending a multicast UPDATE packet on the LAN. B and C both receive it and send acknowledgments back. Router B gets the UPDATE, but its acknowledgment gets lost on the network 😭 Before the retransmission timer for Router B's packet runs out, something happens that causes a brand new multicast UPDATE to go out.
Router A notices that at least one neighbor on the interface has a full queue. That means it MUST tell that neighbor not to receive the next packet, or the neighbor would get the retransmitted packet out of order 🙈 If every neighbor on the interface has a full queue, then EIGRP should reschedule the UPDATE transmission once the queues are no longer full.
Router A then builds a HELLO packet with a SEQUENCE_TYPE TLV that lists all the neighbors with full queues. In this case, the only neighbor address on the list is Router B. The HELLO is sent out the interface via multicast, unreliably 🧚
Routers C and D check the SEQUENCE_TYPE TLV by looking for their own addresses in the list. If they don't find themselves there, they put themselves in CR-Mode.
Router B doesn't find its address in the SEQUENCE TLV peer list, so it enters CR-Mode. Any packets B receives with the CR-Flag MUST be discarded and not acknowledged 🚫
Later, Router A unicasts both packet 100 and packet 101 directly to Router B. B already has 100, so it discards it and acknowledges it. Then B accepts and acknowledges packet 101. Once that acknowledgment arrives, Router A can remove both packets from Router B's transmission list ✨
5.2.1. Bandwidth on Low-Speed Links ✨
By default, EIGRP limits itself to using no more than 50% of the bandwidth an interface reports when it works out packet-pacing intervals. If the bandwidth doesn't match the physical bandwidth (the network architect might have set an artificially low or high bandwidth value to influence routing decisions), EIGRP may:
- Generate more traffic than the interface can handle, possibly causing drops, which hurts EIGRP performance 📉
- Generate so much EIGRP traffic that very little bandwidth is left for user data. To keep these transmissions under control, an interface-pacing timer is defined for the interfaces where EIGRP is enabled. When a pacing timer expires, a packet is transmitted out on that interface ⏰
5.3. Neighbor Discovery/Recovery 🦋
Neighbor Discovery/Recovery is how routers dynamically learn about other routers on their directly attached networks. Routers MUST also discover when their neighbors become unreachable or inoperative 👀 This is done with low overhead by periodically sending small HELLO packets. As long as any packets are received from a neighbor, the router can tell that the neighbor is alive and functioning. Only once a neighbor router is considered operational can the neighboring routers exchange routing information 💜
5.3.1. Neighbor Hold Time ⏳
Each router keeps state information about its adjacent neighbors. When a neighbor is newly discovered, the router notes its address, interface, and Hold Time. When a neighbor sends a HELLO, it advertises its Hold Time. The Hold Time is how long a router treats a neighbor as reachable and operational. Besides the HELLO packet, if any packet is received within the Hold Time period, the Hold Time period gets reset 🔄 When the Hold Time expires, DUAL is informed of the topology change.
5.3.2. HELLO Packets 👋
When an EIGRP router initializes, it starts sending HELLO packets out any interface where EIGRP is enabled. When HELLO packets are used for neighbor discovery, they're normally sent multicast addressed. The HELLO packet includes the configured EIGRP metric K-values. Two routers become neighbors only if their K-values match. This makes sure the metric usage is consistent throughout the Internet 🌈 The HELLO packet also includes a Hold Time value, which tells all receivers how many seconds the neighbor is valid. The default Hold Time is three times the HELLO interval. HELLO packets are 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 🍓
5.3.3. UPDATE Packets 📦
A router detects a new neighbor when it receives a HELLO packet from a neighbor it doesn't already know. To make sure unicast and multicast packets get delivered, the detecting router sends a unicast UPDATE packet to the new neighbor with no routing information. This is 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 make sure bidirectional UNICAST packet delivery works, since the NULL UPDATE and the ACK are both sent unicast. Additional UPDATE packets can't be sent until the initial NULL UPDATE packet has been acknowledged ✅
The INIT-Flag tells the neighbor to advertise its routes. It's also useful when a neighbor goes down and comes back up before the router notices it went down. In that case, the neighbor needs new routing information, and the INIT-Flag is how the router asks for it to be sent 🙌
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. If it doesn't, a Cisco device will post a "stuck in INIT state" error and subsequently discard packets 💀
5.3.4. Initialization Sequence ✨
Okay bestie, let's watch two routers boot up together 🧚. Router A just woke up, and Router B has been running the whole time. Here's the handshake, step by step 💜:
Router A Router B
(just booted) (up and running)
(1)---------------->
HELLO (multicast) <---------------- (2)
SEQ=0, ACK=0 HELLO (multicast)
SEQ=0, ACK=0
<---------------- (3)
UPDATE (unicast)
SEQ=10, ACK=0, INIT
(4)----------------> UPDATE 11 is queued
UPDATE (unicast)
SEQ=100, ACK=10, INIT <---------------- (5)
UPDATE (unicast)
SEQ=11, ACK=100
All UPDATES sent
(6)--------------/lost/->
ACK (unicast)
SEQ=0, ACK=11
(5 seconds later)
<---------------- (7)
Duplicate received, UPDATE (unicast)
packet discarded SEQ=11, ACK=100
(8)--------------->
ACK (unicast)
SEQ=0, ACK=11
Figure 9: Initialization Sequence(1) Router A sends a multicast HELLO and Router B discovers it. 👀
(2) Router B sends an expedited HELLO and starts sending its topology table to Router A. 🚀 It also sends the NULL UPDATE packet with the INIT-Flag. That second packet gets queued, and it can't go out until the first one is acknowledged 🫶.
(3) Router A receives the first UPDATE packet and processes it as a DUAL event. If the UPDATE has topology information, it gets processed and stored in a topology table 🗂️. Router B sends its first and only UPDATE packet, with an accompanying ACK ✨.
(4) Router B receives UPDATE packet 100 from Router A. Since that UPDATE acknowledged 10, Router B can dequeue packet 10 from A's transmission list 🧹. Now it can send UPDATE packet 11, along with an acknowledgment of Router A's UPDATE 💅.
(5) Router A receives the last UPDATE packet from Router B and acknowledges it. Oof, that acknowledgment gets lost 😭.
(6) Router B retransmits the UPDATE packet to Router A later on 🔁.
(7) Router A spots the duplicate and just acknowledges the packet 🙈. Router B dequeues packet 11 from A's transmission list, and both routers are up and synchronized 🎀👑.
5.3.5. Neighbor Formation
Here's the vibe: to avoid sending packets to a neighbor before we've confirmed that multicast and unicast delivery actually work, we use a three-way handshake 🤝.
During normal adjacency formation, multicast HELLOs make the EIGRP process put new neighbors into the neighbor table 📝. Then unicast packets exchange known routing information and finish the neighbor relationship (Section 5.2) 💖.
Now, to stop EIGRP from sending sequenced packets to neighbors that don't have two-way unicast/multicast working, or to neighbors that restart partway through building the relationship, EIGRP MUST place the newly discovered neighbor in a "pending" state. Here's how that goes:
- When Router A receives the first multicast HELLO from Router B, it puts Router B in the pending state and sends a unicast UPDATE with no topology information. That UPDATE SHALL have the initialization bit set 🚩.
- While Router B is pending, A won't send it a QUERY or an UPDATE 🙅♀️.
- When Router A gets the unicast acknowledgment from Router B, it switches Router B from "pending" to "up" 🎉.
5.3.6. QUERY Packets during Neighbor Formation
As we just covered, when a neighbor relationship is first forming, EIGRP uses a sort of three-way handshake to check that unicast and multicast connectivity are both working 🔍. During this time, the new neighbor counts as pending, and it's not eligible to be part of the convergence process 🙈.
So, any QUERY an EIGRP router receives won't cause a QUERY to go out to that new, pending neighbor. The router runs the DUAL process without the new peer in the conversation 💅. To make that happen, when a router that's setting up a new neighbor gets a QUERY from a fully established neighbor, it runs the normal DUAL Feasible Successor check. That check decides whether it can REPLY with a valid path or whether it has to go ACTIVE on the prefix 🧠.
If it decides it has to go active, each fully established neighbor that's taking part in convergence gets a QUERY packet, and REPLY packets are expected back from each one 📬. Pending neighbors won't be expected to REPLY, and they won't be sent a QUERY directly 🫥. If an interface has a mix of fully established and pending neighbors, a pending neighbor might still receive the QUERY, but it isn't expected to REPLY to it 🌸.
5.4. Topology Table
The topology table gets filled in by the Protocol-Dependent Modules (PDMs) (IPv4/IPv6), and the DUAL finite state machine is the one that acts on it 🧩. Each entry holds the destination address, a list of neighbors that advertised that destination, and the metric for that destination 📋. The metric is called the "CD" 💜.
The CD is the best-advertised RD from all neighbors, plus the link cost between the receiving router and that neighbor 🧮.
The "RD" is the CD as advertised by the Feasible Successor for the destination. In other words, when a neighbor sends its Computed Distance, it's called the "Reported Distance", and it's the metric 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, and distance vector protocols MUST follow it 🚨.
5.4.1. Route Management
Inside the topology table, EIGRP has internal and external routes 🗺️. Internal routes MUST be preferred over external routes, independent of the metric. In practice, if an internal route is received, the diffusing computation runs considering only the internal routes 🏠. Only when no internal routes exist for a given destination will EIGRP pick the successor from the available external routes 🌍.
5.4.1.1. Internal Routes
Internal routes are destinations that were originated within the same EIGRP AS 🏡. So a directly attached network configured to run EIGRP counts as an internal route, and it gets propagated through the whole network topology 🌐.
Internal routes are tagged with the following info:
- Router ID of the EIGRP router that originated the route.
- Configurable administrator tag.
5.4.1.2. External Routes
External routes are destinations learned from another source, like a different routing protocol or a static route 🛣️. Each of these routes is marked with the identity of where it came from 🏷️. External routes are tagged with the following info:
- Router ID of the EIGRP router that redistributed the route.
- AS number where the destination resides.
- Configurable administrator tag.
- Protocol ID of the external protocol.
- Metric from the external protocol.
- Bit flags for default routing.
Let's walk through an example 🎀. Picture an AS with three border routers: BR1, BR2, and BR3. A border router is one that runs more than one routing protocol. This AS uses EIGRP as its routing protocol. Two of the border routers, BR1 and BR2, also run Open Shortest Path First (OSPF) [10], and the other one, BR3, also runs the Routing Information Protocol (RIP) 💅.
Routes learned by one of the OSPF border routers, BR1, can be conditionally redistributed into EIGRP. That means EIGRP running on BR1 advertises the OSPF routes inside its own AS 📣. When it does, 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 then propagates to the other border routers 🌊.
Now say BR3, the RIP border router, also advertises the same destinations as BR1. So BR3 redistributes the RIP routes into the EIGRP AS 🔁. BR2 then has enough info to figure out the AS entry point for the route, the original routing protocol used, and the metric 🧠.
On top of that, the network admin can assign tag values to specific destinations while redistributing the route 🏷️. BR2 can use any of this info to use the route or to re-advertise it back out into OSPF 🔄.
Route tagging gives network admins flexible policy controls and helps them customize routing, which is so iconic 👑. It's especially useful in transit ASes, where EIGRP typically interacts with an inter-domain routing protocol that enforces global policies 🌈.
5.4.2. Split Horizon and Poison Reverse
Sometimes EIGRP will suppress or poison QUERY and UPDATE information to prevent routing loops while changes spread through the network 🌀.
In Cisco land, the split horizon rule says: "Never advertise a route out of the interface through which it was learned". EIGRP takes that 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 says: "A route learned through an interface will be advertised as unreachable through that same interface". Just like split horizon, EIGRP only applies this rule to interfaces it's actually using to reach the destination. Routes learned through interfaces that EIGRP is not using to reach the destination can still be advertised out those interfaces 🦋.
In EIGRP, split horizon suppresses a QUERY, whereas poison reverse advertises a destination as unreachable 🫣. This can happen for a destination under any of these conditions:
- two routers are in startup or restart mode
- advertising a topology table change
- sending a query
5.4.2.1. Startup Mode
When two routers first become neighbors, they exchange topology tables during startup mode 🤝. For each destination a router receives during startup mode, it advertises that same destination back to its new neighbor with a maximum metric (Poison Route) ☠️💖.
5.4.2.2. Advertising Topology Table Change
If a router uses a neighbor as the successor for a given destination, it sends an UPDATE for that destination with a metric of infinity 🚫.
5.4.2.3. Sending a QUERY/UPDATE
Most of the time, EIGRP follows normal split-horizon rules 🎀. When a metric change comes in from the successor via QUERY or UPDATE and that causes the route to go ACTIVE, the router sends a QUERY to neighbors on all interfaces except the interface toward the successor 🧭.
In other words, the router doesn't send the QUERY out of the inbound interface through which the info that made the route go ACTIVE was received 🙅♀️.
There's one exception. If a router gets a QUERY from its successor while it's already reacting to an event that didn't make it go ACTIVE, the router can still end up going ACTIVE. For example, a metric change from the successor that didn't cause an ACTIVE transition, followed by the UPDATE/QUERY that does make the router transition to ACTIVE 🌟.
5.5. EIGRP Metric Coefficients ✨
okay so EIGRP lets you tweak the default composite metric (see Section 5.6) with coefficients called K-values 🎀 This is how you tune network behavior for each deployment. You can set K-values up to 254, and that scales how much the scalar metric affects the final composite metric 💅
The default coefficients were picked super carefully to give optimal performance in most networks 🌸 Here are the defaults:
K1 == K3 == 1
K2 == K4 == K5 == 0
K6 == 0If K5 is equal to 0, the reliability quotient is defined to be 1 🦋
5.5.1. Coefficients K1 and K2 💖
K1 lets path selection be based on the bandwidth available along the path 🌈 EIGRP can use one of two Throughput-based variations:
- Maximum Theoretical Bandwidth: paths chosen based on the highest reported bandwidth
- Network Throughput: paths chosen based on the highest "available" bandwidth, adjusted by congestion-based effects (interface reported load)
By default, EIGRP works out Throughput from the maximum theoretical Throughput, expressed in picoseconds per kilobyte of data sent. The inversion means a bigger number (more time), which ends up giving a worse metric 🙈
If K2 is used, the congestion effect (the load the interface reports) is used to simulate the "available Throughput" by adjusting the maximum Throughput ✨
5.5.2. Coefficient K3 🧚
K3 lets path selection be based on delay or latency 🍓 Latency and delay are similar terms for 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 let path selection be based on link quality and packet loss 😭 Packet loss caused by network problems leads to really noticeable performance issues, or Jitter, with streaming, voice over IP, online gaming and videoconferencing, and it affects every other network application to some degree.
Critical services should pass with less than 1% packet loss. Lower priority packet types might pass with less than 5%, and the lowest priority services with less than 10% 🫶 The final metric can be weighted based on the reported link quality.
K5 is conditional, so be careful with it 👑 If K5 is equal to 0, then the reliability quotient is defined to be 1.
5.5.4. Coefficient K6 🌸
K6 came along with Wide Metric support, and it's used to allow for Extended Attributes. These can be used to reflect in a higher aggregate metric than those with lower energy usage 🔥 Right now there are two Extended Attributes defined in this document: Jitter and energy.
5.5.4.1. Jitter 🎀
Jitter-based Path Selection gives a path calculation with the lowest reported Jitter 💅 Jitter is reported as the interval between the longest and shortest packet delivery, and it's expressed in microseconds. Higher values result in a higher aggregate metric compared to those with lower Jitter calculations.
Jitter is measured in microseconds and accumulated along the path, with each hop using an averaged 3-second period to smooth out the rate of metric change ✨
Presently, EIGRP can't measure Jitter, so the default value is zero (0) 🙈 Performance-based solutions such as PfR could be used to populate this field.
5.5.4.2. Energy 🍓
Energy-based Path Selection picks the paths with the lowest energy usage, in a loop-free and deterministic manner 🌈 Energy used is accumulative, and it results in a higher aggregate metric for paths with higher energy usage.
Right now EIGRP doesn't report energy usage, so the default value is zero (0) 🦋
5.6. EIGRP Metric Calculations 💖
5.6.1. Classic Metrics 🌸
The composite metric is based on bandwidth, delay, load, and reliability. MTU isn't an attribute used to calculate the composite metric, but it is carried in the vector metrics 🎀
One of the original goals of EIGRP was to offer and enhance routing solutions for IGRP. To do that, 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 this 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 as percentages, with a value of 1 to 255 ✨
Implementation note: Cisco IOS routers display reliability as a fraction of 255. That means 255/255 is 100% reliability (a perfectly stable link), and 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, and a load of 127/255 represents a 50% saturated link. These values aren't dynamically measured; they're 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:
(10^7)/BWminImplementation note: When converting the real bandwidth to the composite bandwidth, truncate before applying the scaling factor. When converting the composite bandwidth back 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 its maximum value (hexadecimal 0xFFFFFFFF) indicates that the network is unreachable 😭 The formula for delay is:
[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,000And 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 table below shows the times in nanoseconds that 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 Gig5.6.2. Wide Metrics 🦋
To let EIGRP do path selection for interfaces with high bandwidths, both the EIGRP packet and the composite metric formula have been modified 🔥 This change lets EIGRP choose paths based on the computed time (measured in picoseconds) that information takes to travel through 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 - accumulativeThere are two additional values, Jitter and energy. These two values are accumulated from destination to source:
o Jitter - accumulative
o Energy - accumulativeThese Extended Attributes, along with any future ones, are controlled via K6. If K6 is non-zero, these are additive to the path's composite metric 🌈 Higher Jitter or energy usage results in paths that are worse than those that either don't monitor these attributes or have lower values.
EIGRP won't send these attributes if the router doesn't provide them. If the attributes are received, EIGRP uses them in the metric calculation (based on K6) and forwards them, with that router's values assumed to be "zero", and the accumulative values are forwarded unchanged 🫶
The vector metrics let EIGRP compute paths based on any of four path selection schemes: bandwidth, delay, reliability, and load. The schemes are told apart by the choice of 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 doesn't 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 that increases with each segment in the path.
Network Designer note: If you're trying to manually influence EIGRP path selection through interface bandwidth or delay configuration, changing bandwidth is discouraged, for the following reasons 🙈 The change only affects path selection if the configured value is the lowest bandwidth over the entire path. Changing the bandwidth can have impact beyond the EIGRP metrics. For example, Quality of Service (QoS) also looks at the bandwidth on an interface. EIGRP throttles its packet transmissions so it only uses 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 doesn't 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 ✨
okay so EIGRP has a little stash of constants it uses for converting and calculating metric values 💅 here they are 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 65536bestie, when you're doing the metric math with these units, all capacity info gets normalized to kilobytes and picoseconds first 🧚 so delay is expressed in microseconds per kilobyte, and then gets converted to kilobytes per second. likewise, energy is expressed in power per kilobytes per second of usage 🔋💖
5.6.2.3. Throughput Calculation 🦋
the formula for converting to a Max-Throughput value straight from the interface, without factoring in congestion-based effects, looks like this:
(EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE)
Max-Throughput = K1 * ------------------------------------
Interface Bandwidth (kbps)if K2 is used, the congestion effect (the load the interface reports) gets used to simulate the "available Throughput" by tweaking the max Throughput with this formula:
K2 * Max-Throughput
Net-Throughput = Max-Throughput + ---------------------
256 - LoadK2 has the greatest effect on the metric occurs when the load increases beyond 90%. the way it spikes past 90% is giving drama 😭🔥
5.6.2.4. Latency Calculation 🌸
okay this part is serious, no cap 🫶 transmission times derived from physical interfaces MUST be n units of picoseconds, converted to picoseconds before they get exchanged between neighbors or used in the composite metric determination.
this also covers delay values that show up in configuration-based commands (i.e., interface delay, redistribute, default-metric, route-map, etc.) 🍓
then the delay value gets turned into a "latency" with this formula:
Delay * EIGRP_WIDE_SCALE
Latency = K3 * --------------------------
EIGRP_DELAY_PICO5.6.2.5. Composite Calculation 💜
the composite metric formula is the glow-up moment ✨
K5
metric =[(K1*Net-Throughput) + Latency)+(K6*ExtAttr)] * ------
K4+Relby default, the path selection scheme EIGRP uses is a combo of Throughput and Latency, where the selection is a product of total latency and minimum Throughput of all links along the path 👑 in other words:
metric = (K1 * min(Throughput)) + (K3 * sum(Latency)) }6. EIGRP Packet Formats 🎀
6.1. Protocol Number 🦋
the IPv6 and IPv4 protocol identifier number spaces are shared, and both use protocol identifier 88 [8] [9] 💅
EIGRP IPv4 transmits HELLO packets either to the unicast destination of a neighbor, or to a multicast host group address [7], with a source address of the EIGRP IPv4 multicast address [13].
EIGRP IPv6 transmits HELLO packets with a source address set to the link-local address of the transmitting interface. multicast HELLO packets have a destination address of the EIGRP IPv6 multicast address [14]. unicast packets aimed at a specific neighbor contain that neighbor's link-local destination address 🧚
there's no requirement that two EIGRP IPv6 neighbors share a common prefix on their connecting interface, which is lowkey so freeing 🌈 EIGRP IPv6 will check that a received HELLO contains a valid IPv6 link-local source address. other HELLO processing follows the common EIGRP checks, including matching AS number and matching K-values 🫶
6.2. Protocol Assignment Encoding 💖
the External Protocol field is an informational assignment that identifies the originating routing protocol a route was learned from. these 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 ✨
destination types are encoded according to the IANA address family number assignments. right now only these 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 163866.4. EIGRP Communities Attribute 🌈
EIGRP supports communities that are similar to the BGP Extended Communities RFC 4360 [4] extended type. the Type field is 2 octets and the Value field is 6 octets. each Community is encoded as an 8-octet quantity, like this:
- 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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+on top of the well-known communities BGP supports (like Site of Origin), EIGRP defines a bunch of extra Community values in the "Experimental Use" [5] range, and they're giving main character energy 👑
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 + RouterID6.5. EIGRP Packet Header 🦋
the basic EIGRP packet payload format is identical for IPv4 and IPv6, though there are some protocol-specific variations 💅 packets are a header followed by a set of variable-length fields made 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: the EIGRP Packet Header Format version. the 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 these 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 11Checksum: each packet includes a checksum for its entire contents. the checksum is the standard ones' complement of the ones' complement sum. for 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 tells 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 router's 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 indicate 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 means the neighbor has finished sending all UPDATEs. at that point, the router removes any stale routes it learned from the neighbor before the restart event. a stale route is any route that existed before the restart and was not refreshed by the neighbor via an UPDATE 🧹
Sequence Number: each transmitted packet has a 32-bit sequence number that is unique with respect to a sending router. a value of 0 means an acknowledgment is not required 🦋
Acknowledgment Number: the 32-bit sequence number being acknowledged with respect to the receiver of the packet. if the value is 0, no acknowledgment is 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 this packet is associated with. packets received with an unknown, or unsupported, value are discarded 🚫
Value Range Usage
0x0000 Unicast Address Family
0x0001 Multicast Address Family
0x0002-0x7FFF Reserved
0x8000 Unicast Service Family
0x8001-0xFFFF ReservedAutonomous System Number: a 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 ✨
okay so every packet can carry a bunch of fields, and each one gets a tag plus a length 🎀 this is lowkey genius because newer software can add new stuff and still hang with the old software in the same setup 🫶 any field your router doesn't recognize just gets skipped over. no drama. 💅 another win is that multiple network-layer protocols can carry their own separate info, so if anyone ever wants to build one big "integrated" protocol later, the door is open 🦋
the {type, length, value} (TLV) layout looks like this:
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 listed further down 📝 the length value counts the octets in the type, length, and value fields together 🧚 TLVs can show up in any order inside a packet, and none of them depend on each other 💖
now the bad news 🙈 if a TLV is malformed, the whole message that holds it gets silently discarded. a TLV counts as malformed when its Length is invalid, or when it runs past the end of the message it sits in. yikes, so double-check those lengths bestie 😭
6.6.1. Type Field Encoding
the type field has a high part and a low part 🌸
Type High is 1 octet that tells you the protocol classification. here's the lineup:
Protocol ID VERSION
General 0x00 1.2
IPv4 0x01 1.2
IPv6 0x04 1.2
SAF 0x05 3.0
Multiprotocol 0x06 2.0Type Low is also 1 octet, and it defines the TLV Opcode. go check out TLV Definitions in Section 3 for the full list 🍓
6.6.2. Length Field Encoding
the Length field is a 2-octet unsigned number that tells you how long the TLV is. the count includes both the Type and the Length fields themselves 🎀
6.6.3. Value Field Encoding
the Value field is a multi-octet field that holds the payload for the TLV 💜
6.7. EIGRP Generic TLV Definitions 👑
here's the table of generic TLVs and their codes for Version 1.2 and Version 2.0 🦋 it's giving organized 🫶
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 --- 0x00086.7.1. 0x0001 - PARAMETER_TYPE
this TLV shows up in HELLO packets and carries the EIGRP metric coefficient values, which are called the "K-values," plus the Hold Time values 💅 it also gets used in an initial UPDATE packet when a neighbor is first 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 are the K-values for the EIGRP composite metric equation 🔥 the default weights are:
K1 - 1
K2 - 0
K3 - 1
K4 - 0
K5 - 0
K6 - 0Hold Time is how many seconds a receiving router should treat the sending neighbor as valid ⏰ a valid neighbor is one that can forward packets and takes part in EIGRP. a router that sees a neighbor as valid stores all of the routing info that neighbor advertises 🌈
6.7.2. 0x0002 - AUTHENTICATION_TYPE
this TLV can show up in any EIGRP packet, and it tells everyone which authentication type and data are being used 🔐 if a router gets a mismatch in authentication, it shall discard the packet. no exceptions, bestie 😤
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 is the type of authentication being used 💖
Authentication Length is the length, in octets, of that one authentication 🎀
Authentication Data is a variable-length field whose size is set by "Auth Length." what goes in it depends on the authentication type in use 🧚 one AUTHENTICATION_TYPE TLV can hold more than one authentication type at the same time 🫶
6.7.2.1. 0x02 - MD5 Authentication Type
MD5 Authentication uses Auth Type code 0x02, and its Auth Data is the MD5 Hash value 🔑
6.7.2.2. 0x03 - SHA2 Authentication Type
SHA2-256 Authentication uses Type code 0x03, and its Auth Data is the 256-bit SHA2 [6] Hash value 🔒
6.7.3. 0x0003 - SEQUENCE_TYPE
this TLV is how a sender tells receivers not to accept packets that have the CR-Flag set 🚫 it's used to put multicast and unicast addressed packets in order 📦
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 pair repeats one or more times, depending on the Length field 🔁
Address Length is how many octets the following address takes up. IPv4 is 4, IPv6 is 16. AppleTalk was 4 and Novell IPX was 10, but both are no longer in use 🕰️
Protocol Address is the neighbor address on the interface where the HELLO with SEQUENCE TLV was sent. every address listed in that HELLO packet is a neighbor that should not enter Conditionally Received mode 🙅♀️
6.7.4. 0x0004 - SOFTWARE_VERSION_TYPE
the EIGRP TLV Version fields are what routers use to figure out TLV format versions 🧩 routers running Version 1.2 TLVs don't understand Version 2.0 TLVs, so in a mixed network, Version 2.0 routers have to send the packet with both TLV formats 🌸
Field Length
Vender OS major version 1
Vender OS minor version 1
EIGRP major revision 1
EIGRP minor revision 1 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x0004 | 0x000C |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vendor Major V.|Vendor Minor V.| EIGRP Major V.| EIGRP Minor V.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+6.7.5. 0x0005 - MULTICAST_SEQUENCE_TYPE
this one is all about 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 isn't part of this document 🤐
6.7.7. 0x0007 - PEER_ TERMINATION_TYPE
this TLV shows up in HELLO packets to tell the neighbor(s) that the router has reset the adjacency 💀 it's used any time a router needs to reset an adjacency, or to signal that an adjacency 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
this is the list of sub-topology identifiers the router supports, and it includes the Base Topology 🗺️
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 info changes from the last state, that means either a new topology got added or an existing one got removed 📊 this TLV gets ignored until the three-way handshake has finished 🤝
when a TID list comes in, the router compares it to the last list it sent. if it finds a TID that didn't exist before, that TID gets added to the neighbor's topology list, and the existing sub-topology is sent to the peer 📬
if a TID from a previous list doesn't show up anymore, that TID gets removed from the neighbor's topology list, and every route learned through that neighbor for that sub-topology is removed from the topology table 🗑️
6.8. Classic Route Information TLV Types 🛣️
6.8.1. Classic Flag Field Encoding
EIGRP carries a few flags inside the TLVs to show extra route state info 🚩 here's how the bits are defined:
Flags Field
-----------Source Withdraw (Bit 0) shows whether the router that originally sourced the destination is withdrawing the route from the network, or whether the destination got lost because of a network failure 😵
Candidate Default (CD) (Bit 1) is set to show the destination should be treated as a candidate for the default route 🎀 an EIGRP default route is picked from all the advertised candidate default routes, whichever one has the smallest metric ✨
ACTIVE (Bit 2) shows whether the route is in the ACTIVE State 🔥
6.8.2. Classic Metric Encoding 📏✨
okay so this section is about how Classic TLVs handle bandwidth and delay. the numbers are "scaled" compared to what's actually on the physical link, which is lowkey genius because it lets everything fit in a neat little 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scaled Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scaled Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reliability | Load | Internal Tag | Flags Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Scaled Delay 🐢: an administrative parameter that's set statically per interface type. it's the time it takes along an unloaded path, expressed in units of tens of microseconds divvied by 256. and a delay of 0xFFFFFFFF means the route is unreachable 💀
- Scaled Bandwidth 🚀: the path bandwidth measured in bits per second, in units of 2,560,000,000/kbps.
- 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 means 100% reliability.
- Load 🏋️♀️: the load utilization of the path to the destination, measured as a percentage. a value of 255 means 100% load.
- Internal-Tag 🏷️: a tag the network admin assigns, which EIGRP doesn't touch. it lets the admin filter routes in other EIGRP border routers based on this value. iykyk 🫶
- Flags Field 🚩: see Section 6.8.1.
6.8.3. Classic Exterior Encoding 🌍
okay so this one is for destinations outside of the EIGRP AS. the extra routing info goes like this:
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 the sending router provides to uniquely identify itself as the source.
- External Autonomous System (AS) Number 🔢: a 32-bit number for the external AS the sending router belongs to. if the source protocol is EIGRP, this field is the [VRID, AS] pair. if the external protocol doesn't have an AS, other info can be used (for example, Cisco uses process-id for OSPF).
- Administrative Tag 🏷️: a tag the network admin assigns, which EIGRP leaves alone. it lets the admin filter routes in other EIGRP border routers based on this value.
- External Protocol Metric 📊: a 32-bit value of the composite metric that sits 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 info gets stored in the metric section.
- External Protocol 🧩: an enumerated value defined in Section 6.2 that identifies the routing protocol (external protocol) redistributing the route.
- Flags Field 🚩: see Section 6.8.1
6.8.4. Classic Destination Encoding 🎯
EIGRP carries destinations in a compressed form, where a counter tells you how many bits are significant in the variable-length address field. so cute, right? 🥹
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 🔢: an 8-bit value for the number of bits in the subnet mask. a value of 0 means the default network, and no address is present.
- Destination Address 📍: a variable-length field for the destination address. the length depends on the number of consecutive bits in the destination address. the formula is address-family dependent:
IPv4: ((Bit Count - 1) / 8) + 1
IPv6: (Bit Count == 128) ? 16 : ((x / 8) + 1)6.8.5. IPv4-Specific TLVs 🌸
INTERNAL_TYPE 0x0102
EXTERNAL_TYPE 0x0103
COMMUNITY_TYPE 0x01046.8.5.1. IPv4 INTERNAL_TYPE 🏠
this TLV carries IPv4 destination and associated metric info for IPv4 networks. the routes advertised here are network interfaces EIGRP is configured on, plus networks learned from other EIGRP routers. 🛣️
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x02 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-Hop Forwarding Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vector Metric Section (see Section 6.8.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Destination Section |
| IPv4 Address (variable length) |
| (see Section 6.8.4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next-Hop Forwarding Address 🦋: an IPv4 address made of four 8-bit values (4 octets total). if it's zero (0), the IPv4 address from the received IPv4 header is used as the next hop for the route. otherwise, the specified IPv4 address gets used.
- Vector Metric Section 📈: the vector metrics for destinations in this TLV. see the "metric encoding" bit in Section 6.8.2.
- Destination Section 📍: the network/subnet/host destination address being requested. see the "destination" bit in Section 6.8.4.
6.8.5.2. IPv4 EXTERNAL_TYPE 🌏
this TLV carries IPv4 destination and metric info for routes learned by other routing protocols that EIGRP injects into the AS. it also tells you which routing protocol created the route, the external metric, the AS number, whether it should be marked as part of the EIGRP AS, and an admin tag for filtering at AS boundaries. so much info, bestie 😭
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 | 0x03 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-Hop Forwarding Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exterior Section (see Section 6.8.3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vector Metric Section (see Section 6.8.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Destination Section |
| IPv4 Address (variable length) |
| (see Section 6.8.4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next-Hop Forwarding Address 🦋: an IPv4 address made of four 8-bit values (4 octets total). if it's zero (0), the IPv4 address from the received IPv4 header is used as the next hop for the route. otherwise, the specified IPv4 address gets used.
- Exterior Section 🌍: extra routing info for a destination outside the AS that got redistributed into EIGRP. see the "exterior encoding" bit in Section 6.8.3.
- Vector Metric Section 📈: vector metrics for destinations in this TLV. see the "metric encoding" bit in Section 6.8.2.
- Destination Section 📍: the network/subnet/host destination address being requested. see the "destination" bit in Section 6.8.4.
6.8.5.3. IPv4 COMMUNITY_TYPE 🏘️
this TLV is used to attach community tags to 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 the community info should be stored with.
- Community Length 📏: a 2-octet unsigned number for the length of the Community List. the length doesn't include the IPv4 Address, Reserved, or Length fields.
- Community List 💜: one or more 8-octet EIGRP communities, as defined in Section 6.4.
6.8.6. IPv6-Specific TLVs 🌈
INTERNAL_TYPE 0x0402
EXTERNAL_TYPE 0x0403
COMMUNITY_TYPE 0x04046.8.6.1. IPv6 INTERNAL_TYPE ✨
okay so this TLV is where EIGRP carries the IPv6 destination plus its metric info for IPv6 networks 🌐 The routes in here are the network interfaces EIGRP is configured on, and the networks it learned from other EIGRP routers. main character energy for IPv6 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x04 | 0x02 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Next-Hop Forwarding Address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vector Metric Section (see Section 6.8.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Destination Section |
| IPv6 Address (variable length) |
| (see Section 6.8.4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next-Hop Forwarding Address 🧭: this IPv6 address is eight groups of 16-bit values, so 16 octets total. If it's zero (0), the IPv6 address from the received IPv6 header becomes the next hop for the route. Otherwise, the address you specified is the one that gets used. 🫶
- Vector Metric Section 📊: the vector metrics for the destinations in this TLV. Check out "metric encoding" in
Section 6.8.2for the full tea ☕ - Destination Section 🎯: the network/subnet/host destination address being requested. The deets on "destination" live in
Section 6.8.4💖
6.8.6.2. IPv6 EXTERNAL_TYPE 🌸
ngl this one is the drama queen 🎭 It carries IPv6 destination and metric info for routes that other routing protocols created and EIGRP injected into the topology. Riding along with that is the identity of the routing protocol that made the route, the external metric, the AS number, a flag for whether it should be marked as part of the EIGRP AS, and a network administrator tag that's used for route filtering at EIGRP AS boundaries. so much info, bestie 😭
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x04 | 0x03 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Next-Hop Forwarding Address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exterior Section (see Section 6.8.3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vector Metric Section (see Section 6.8.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| Destination Section |
| IPv6 Address (variable length) |
| (see Section 6.8.4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Next-Hop Forwarding Address 🧭: IPv6 address, eight groups of 16-bit values (16 octets total). If the value is zero (0), the IPv6 address from the received IPv6 header is used as the next hop. Otherwise, the specified IPv6 address will be used. 💅
- Exterior Section 🌍: extra routing info for a destination that sits outside the AS and got redistributed into EIGRP. The "exterior encoding" details are in
Section 6.8.3✨ - Vector Metric Section 📊: vector metrics for the destinations in this TLV. See "metric encoding" in
Section 6.8.2🎀 - Destination Section 🎯: the network/subnet/host destination address being requested. See "destination" in
Section 6.8.4🦋
6.8.6.3 IPv6 COMMUNITY_TYPE 🏷️
this TLV is how you attach community tags to specific IPv4 destinations 🙈 (yes, the description says IPv4 even though the TLV is the IPv6 one, and I'm not fixing the original, iykyk 💀)
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 the community info should be stored with 💜
- Community Length 🔢: a 2-octet unsigned number that tells you the length of the Community List. It does not count the IPv6 Address, Reserved, or Length fields 🧮
- Community List 🧁: one or more 8-octet EIGRP communities, as defined in
Section 6.4🌈
6.9. Multiprotocol Route Information TLV Types 🌟
this TLV conveys topology and its associated metric info. it's the multiprotocol glow-up 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Header Version | Opcode | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Router ID | Autonomous System Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLV Header Encoding |
| (see Section 6.9.1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Wide Metric Encoding |
| (see Section 6.9.2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Descriptor |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+6.9.1. TLV Header Encoding 🎀
okay so here's the tea 🫖 EIGRP has had a long-standing need to support routing technologies like multi-topologies, and to carry destination info independent of the transport. to make that happen, a Vector got extended with a new "Header Extension Header" section. it's variable-length, and at a minimum it supports the fields below 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type High | Type Low | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | TID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Identifier (RID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the available fields are:
- TYPE 🏷️: Topology TLVs have these TYPE codes:
Type High: 0x06
Type Low:
REQUEST_TYPE 0x01
INTERNAL_TYPE 0x02
EXTERNAL_TYPE 0x03- Router Identifier (RID) 🆔: a 32-bit number that the router sourcing the info provides, so it can be uniquely identified as the source 💅
6.9.2. Wide Metric Encoding 🦋
okay so this part is where the multiprotocol TLVs get their own little extendable section of metric info 🧚 and bestie, it is NOT used for the primary routing compilation, so it's like a bonus stash ✨ the extra per-path info is there so per-path cost calculations can happen later 👑 and when you pair per-path costing with the VID/TID, you get a complete solution for multidimensional routing 🌈 literally iconic 💅
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, served fresh 💖:
- 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 means no Extended Attributes are attached 🙈
- Priority 👑: priority of the prefix when processing a route. In an AS using priority values, a destination with a higher priority gets preferential treatment and is serviced before a destination with a lower priority. A value of zero means 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 😭
6.9.3. Extended Metrics 🌸
okay so extended metrics let the vector metrics be extended in a manner similar to RFC 6390 [11] 💅 each Extended metric shall consist of a header identifying the type (Opcode) and the length (Offset), followed by application-specific information. Extended metric values not understood must be treated as opaque and passed along with the associated route 🔥
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
6.9.3.1. 0x00 - NoOp 🧚
okay this one is just padding 🫶 it's used to pad the attribute section so the metric encoding section stays 32-bit aligned ✨
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, no drama 💅:
- Opcode 🎀: transmitted as zero (0)
- Offset 👑: transmitted as zero (0), indicating no data is present
- Data 💜: no data is present with this attribute
6.9.3.2. 0x01 - Scaled Metric 🦋
okay so 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 it's 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 💀
6.9.3.3. 0x02 - Administrator Tag 🌸
okay so 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 🫶
6.9.3.4. 0x03 - Community List 🦋
okay so EIGRP communities themselves do not alter the path decision-making process 🌈 communities can be used as flags to mark a set of routes, and 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 Section 6.4
6.9.3.5. 0x04 - Jitter ⭐
okay so (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 included 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 🧚
6.9.3.6. 0x05 - Quiescent Energy 🔥
okay so (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 included 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 😭
6.9.3.7. 0x06 - Energy 💜
okay so (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 included 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 🌸
6.9.3.8. 0x07 - AddPath ✨
okay so AddPath is literally how EIGRP shows off multiple best paths to its adjacencies 💅 it's giving multi-path main character energy 🦋 you can have up to a maximum of four AddPaths, and the field format is below. ngl the length of this field changes depending on whether the data is IPv4 or IPv6 🌈
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x07 | Offset | AddPath (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Offset: the number of 16-bit words in the sub-field 🎀
AddPath: its length varies depending on whether it holds IPv4 or IPv6 data 🫶
6.9.3.8.1. AddPath with IPv4 Next Hop
bestie, this one is the IPv4 version 🍓 same vibe as before, just with IPv4 addresses riding along 🧚
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 made of four 8-bit values, so four octets total 💖 if it's zero (0), the IPv6 address from the received IPv4 header becomes the next hop for the route ✨ otherwise, the IPv4 address you specified is used 🌸
Router Identifier (RID): a 32-bit number from the router sending the info, which uniquely identifies it as the source 👑
Admin Tag: a 32-bit administrative tag set by the network 🏷️ it lets a network admin filter routes based on this value 💅
If the route is of type external, then two more bytes get added 🙈
External Protocol: an enumerated value from Section 6.2 that identifies the routing protocol (the external protocol) that's redistributing the route 🦋
Flags Field: see Section 6.8.1 🫶
6.9.3.8.2. AddPath with IPv6 Next Hop
and now the IPv6 version, which is honestly so iconic 😭 the next-hop field is the big one, 16 octets long 🌈
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 made of eight groups of 16-bit values, so 16 octets total 💜 if it's zero (0), the IPv6 address from the received IPv6 header is used as the next hop for the route 🧚 otherwise, the IPv6 address you specified gets used ✨
Router Identifier (RID): a 32-bit number from the router sourcing the info, uniquely identifying it as the source 👑
Admin Tag: a 32-bit administrative tag assigned by the network 🎀 it lets a network admin filter routes based on this value. If the route is of type external, then two extra bytes get added 🙈
External Protocol: an enumerated value from Section 6.2 identifying the routing protocol (the external protocol) redistributing the route 🦋
Flags Field: see Section 6.8.1 💅
6.9.4. Exterior Encoding
okay so this is for destinations outside the EIGRP AS 🌍 the extra routing info looks like this 🍓
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 from the router sourcing the info, uniquely identifying it as the source 👑
External Autonomous System (AS) Number: a 32-bit number for the external AS that the sending router belongs to 🌸 if the source protocol is EIGRP, this field is the [VRID, AS] pair ✨ if the external protocol doesn't have an AS, other info can be used instead (for example, Cisco uses process-id for OSPF) 🧚
External Protocol Metric: a 32-bit value for the metric the routing table uses, as learned from the foreign protocol 💖 if the External Protocol is IGRP or EIGRP, the value can (optionally) be 0, and the metric info gets stored in the metric section 🫶
External Protocol: an enumerated value from Section 6.2 identifying the routing protocol (the external protocol) redistributing the route 🦋
Flags Field: see Section 6.8.1 💅
6.9.5. Destination Encoding
destination info goes into Multiprotocol packets the same way Classic TLVs do it 🎀 the trick is a counter that says how many significant bits are 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: an 8-bit value for the number of bits in the subnet mask 🧚 a value of 0 means the default network, and no address is present 💅
Destination Address: a variable-length field carrying the destination address 🌸 its length depends on how many consecutive bits are in the destination address 🦋 the formula is address-family dependent:
IPv4: ((Bit Count - 1) / 8) + 1
IPv6: (Bit Count == 128) ? 16 : ((x / 8) + 1)6.9.6. Route Information
6.9.6.1. INTERNAL TYPE
this TLV carries destination info based on the IANA AFI from the TLV Header (see Section 6.9.1), plus the associated metric info ✨ the routes advertised here are the network interfaces EIGRP is configured on, along with networks learned from other EIGRP routers 🫶
6.9.6.2. EXTERNAL TYPE
this TLV carries destination info based on the IANA AFI from the TLV Header (see Section 6.9.1), plus metric info for routes that other routing protocols learned and EIGRP injects into the AS 🌈 it also tells you which routing protocol created the route, the external metric, the AS number, whether it should be marked as part of the EIGRP AS, and a network admin tag used for route filtering at EIGRP AS boundaries 💖
7. Security Considerations 💀
okay bestie, this part is serious 🥺 EIGRP is super promiscuous, so it will neighbor with any router that sends a valid HELLO packet 😭 because of that, this "completely" open aspect needs policy capabilities to limit peering to valid routers 🛡️
EIGRP doesn't rely on a PKI or a heavyweight authentication system 🙅♀️ those systems would challenge its scalability, which was a primary design goal ✨
instead, Denial-of-Service (DoS) attack prevention depends on implementations rate-limiting packets to the control plane, plus authentication of the neighbor using MD5 or SHA2-256 [6] 🔥 lowkey this is the part to take seriously 💜
8. IANA Considerations 🌸
this document is the sole reference for two multicast addresses: 224.0.0.10 for IPv4 "EIGRP Routers" [13] and FF02:0:0:0:0:0:0:A for IPv6 "EIGRP Routers" [14] 🦋 it also serves as the assignment for protocol number 88 (EIGRP) [15] 🫶
9. References 📚
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[2] Garcia-Luna-Aceves, J.J., "A Unified Approach to Loop-Free Routing Using Distance Vectors or Link States", SIGCOMM '89, Symposium proceedings on Communications architectures & protocols, Volume 19, pages 212-223, ACM 089791-332-9/89/0009/0212, DOI 10.1145/75247.75268, 1989.
[3] Garcia-Luna-Aceves, J.J., "Loop-Free Routing using Diffusing Computations", Network Information Systems Center, SRI International, appeared in IEEE/ACM Transactions on Networking, Vol. 1, No. 1, DOI 10.1109/90.222913, 1993.
[4] Rosen, E. and Y. Rekhter, "IANA Registries for BGP Extended Communities", RFC 7153, DOI 10.17487/RFC7153, March 2014, <http://www.rfc-editor.org/info/rfc7153>.
[5] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <http://www.rfc-editor.org/info/rfc3692>.
[6] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>.
[7] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <http://www.rfc-editor.org/info/rfc1112>.
[8] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[9] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
9.2. Informative References
[10] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[11] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, DOI 10.17487/RFC6390, October 2011, <http://www.rfc-editor.org/info/rfc6390>.
[12] IANA, "Address Family Numbers", <http://www.iana.org/assignments/address-family-numbers>.
[13] IANA, "IPv4 Multicast Address Space Registry", <http://www.iana.org/assignments/multicast-addresses>.
[14] IANA, "IPv6 Multicast Address Space Registry", <http://www.iana.org/assignments/ipv6-multicast-addresses>.
[15] IANA, "Protocol Numbers", <http://www.iana.org/assignments/protocol-numbers>.
Acknowledgments ✨
okay bestie, time for the shoutouts 🫶 Huge thank you to Dino Farinacci, Bob Albrightson, and Dave Katz! Their brilliant work on the design and development of EIGRP 💖 is the foundation this whole document is built on. Literally iconic.
A super special, extra grateful thank you goes to the core group of Cisco engineers who put in the dedication, long hours, and hard work that carried EIGRP's evolution 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 also want to gratefully acknowledge all the people who joined the discussions that led to 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. Y'all were so helpful 🥹.
Last but not least, the tireless work of the Cisco engineers over the years is amazing, and we want to personally recognize the teams that created open source versions of EIGRP 🧚:
- Linux implementation developed by the Quagga team: Jan Janovic, Matej Perina, Peter Orsag, and Peter Paluch 💜.
- BSD implementation developed and released by Renato Westphal 🍓.
Authors' Addresses 💌
Here's where you can find the authors, bestie 💅. Most of them were at Cisco at the time, so the addresses look a little repetitive, but that's just how it goes 🙈.
Donnie V. Savage
Cisco Systems, Inc.
7025 Kit Creek Rd., RTP,
Morrisville, NC 27560
United States
Phone: 919-392-2379
Email: dsavage@cisco.comJames Ng
Cisco Systems, Inc.
7025 Kit Creek Rd., RTP,
Morrisville, NC 27560
United States
Phone: 919-392-2582
Email: jamng@cisco.comSteven Moore
Cisco Systems, Inc.
7025 Kit Creek Rd., RTP,
Morrisville, NC 27560
United States
Phone: 408-895-2031
Email: smoore@cisco.comDonald Slice
Cumulus Networks
Apex, NC
United States
Email: dslice@cumulusnetworks.comPeter Paluch
University of Zilina
Univerzitna 8215/1, Zilina 01026
Slovakia
Phone: 421-905-164432
Email: Peter.Paluch@fri.uniza.skRuss White
LinkedIn
Apex, NC
United States
Phone: 1-877-308-0993
Email: russw@riw.usThat's the whole RFC, bestie! 🌈✨ Thanks for sticking with me through all 16 parts 🎀💖
📦 where this page comes from
- ietf: rfc7868 2016-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms