idnits 2.17.1 draft-savage-eigrp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (23 Feb 2016) is 2984 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (ref. '9') (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force D. Savage 2 Internet-Draft J. Ng 3 Intended status: Informational S. Moore 4 Expires: August, 2016 Cisco Systems 5 D. Slice 6 Cumulus Networks 7 P. Paluch 8 University of Zilina 9 R. White 10 LinkedIn 11 23 Feb 2016 13 Cisco 14 Enhanced Interior Gateway Routing Protocol 15 draft-savage-eigrp-05.txt 17 Abstract 19 This document describes the protocol design and architecture for 20 Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a routing 21 protocol based on Distance Vector technology. The specific algorithm 22 used is called DUAL, a Diffusing Update Algorithm as reference in 23 "Loop-Free Routing using Diffusing Computations". The algorithm and 24 procedures were researched, developed, and simulated by SRI 25 International. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [1]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering Task 39 Force (IETF). Note that other groups may also distribute working 40 documents as Internet-Drafts. The list of current Internet-Drafts is 41 at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference material 46 or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 16, 2016. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents carefully, 59 as they describe your rights and restrictions with respect to this 60 document. Code Components extracted from this document must include 61 Simplified BSD License text as described in Section 4.e of the Trust 62 Legal Provisions and are provided without warranty as described in the 63 Simplified BSD License. 65 This document may not be modified, and derivative works of it may not 66 be created, except to format it for publication as an RFC or to 67 translate it into languages other than English. 69 Table of Contents 70 1 Introduction..................................................... 6 71 2 Terminology...................................................... 6 72 3 The DUAL Diffusing Update Algorithm.............................. 10 73 3.1 Algorithm Description ....................................... 10 74 3.2 Route States ................................................ 11 75 3.3 Feasibility Condition ....................................... 12 76 3.4 DUAL Message Types .......................................... 14 77 3.5 DUAL Finite State Machine (FSM) ............................. 15 78 3.6 DUAL Operation - Example Topology ........................... 19 79 4 EIGRP Packets.................................................... 21 80 4.1 UPDATE Packets .............................................. 21 81 4.2 QUERY Packets ............................................... 22 82 4.3 REPLY Packets ............................................... 22 83 4.4 Exception Handling .......................................... 23 84 4.4.1 Active Duration (Stuck-in-Active) ....................... 23 85 4.4.1.1 SIA-QUERY............................................ 23 86 4.4.1.2 SIA-REPLY............................................ 24 87 5 EIGRP Protocol Operation......................................... 25 88 5.1 Finite State Machine ........................................ 25 89 5.2 Reliable Transport Protocol ................................. 25 90 5.2.1 Bandwidth on Low-Speed Links ............................ 34 91 5.3 Neighbor Discovery/Recovery ................................. 34 92 5.3.1 Neighbor Hold Time ...................................... 34 93 5.3.2 HELLO Packets ........................................... 34 94 5.3.3 UPDATE Packets .......................................... 35 95 5.3.4 Initialization Sequence ................................. 36 96 5.3.5 Neighbor Formation ...................................... 37 97 5.3.6 QUERY Packets During Neighbor Formation ................. 37 98 5.4 Topology Table .............................................. 38 99 5.4.1 Route Management ........................................ 38 100 5.4.1.1 Internal Routes...................................... 38 101 5.4.1.2 External routes...................................... 39 102 5.4.2 Split Horizon and Poison Reverse ........................ 40 103 5.4.2.1 Startup Mode......................................... 40 104 5.4.2.2 Advertising Topology Table Change.................... 40 105 5.4.2.3 Sending a QUERY/UPDATE............................... 40 106 5.5 EIGRP Metric Coefficients ................................... 41 107 5.5.1 Coefficients K1 and K2 .................................. 41 108 5.5.2 Coefficient K3 .......................................... 41 109 5.5.3 Coefficients K4 and K5 .................................. 42 110 5.5.4 Coefficient K6 .......................................... 42 111 5.5.4.1 Jitter............................................... 42 112 5.5.4.2 Energy............................................... 42 113 5.6 EIGRP Metric Calculations ................................... 43 114 5.6.1 Classic Metrics ......................................... 43 115 5.6.1.1 Classic Composite Formulation........................ 43 116 5.6.2 Wide Metrics ............................................ 45 117 5.6.2.1 Wide Metric Vectors.................................. 45 118 5.6.2.2 Wide Metric Conversion Constants..................... 46 119 5.6.2.3 Throughput Calculation............................... 46 120 5.6.2.4 Latency Calculation.................................. 47 121 5.6.2.5 Composite Calculation................................ 47 122 6 EIGRP Packet Formats............................................ 48 123 6.1 Protocol Number ............................................. 48 124 6.2 Protocol Assignment Encoding ................................ 48 125 6.3 Destination Assignment Encoding ............................. 49 126 6.4 EIGRP Communities Attribute ................................. 49 127 6.5 EIGRP Packet Header ......................................... 50 128 6.6 EIGRP TLV Encoding Format ................................... 52 129 6.6.1 Type Field Encoding ..................................... 52 130 6.6.2 Length Field Encoding ................................... 52 131 6.6.3 Value Field Encoding .................................... 53 132 6.7 EIGRP Generic TLV Definitions ............................... 53 133 6.7.1 0x0001 - PARAMETER_TYPE ................................. 53 134 6.7.2 0x0002 - AUTHENTICATION_TYPE ............................ 54 135 6.7.2.1 0x02 - MD5 Authentication Type....................... 54 136 6.7.2.2 0x03 - SHA2 Authentication Type...................... 54 137 6.7.3 0x0003 - SEQUENCE_TYPE .................................. 54 138 6.7.4 0x0004 - SOFTWARE_VERSION_TYPE .......................... 55 139 6.7.5 0x0005 - MULTICAST_SEQUENCE_TYPE ........................ 55 140 6.7.6 0x0006 - PEER_INFORMATION_TYPE .......................... 55 141 6.7.7 0x0007 - PEER_ TERMINATION_TYPE ......................... 55 142 6.7.8 0x0008 - TID_LIST_TYPE .................................. 56 143 6.8 Classic Route Information TLV Types ......................... 57 144 6.8.1 Classic Flag Field Encoding ............................. 57 145 6.8.2 Classic Metric Encoding ................................. 57 146 6.8.3 Classic Exterior Encoding ............................... 58 147 6.8.4 Classic Destination Encoding ............................ 59 148 6.8.5 IPv4 Specific TLVs ...................................... 60 149 6.8.5.1 IPv4 INTERNAL_TYPE................................... 60 150 6.8.5.2 IPv4 EXTERNAL_TYPE................................... 61 151 6.8.5.3 IPv4 COMMUNITY_TYPE.................................. 62 152 6.8.6 IPv6 Specific TLVs ...................................... 63 153 6.8.6.1 IPv6 INTERNAL_TYPE................................... 63 154 6.8.6.2 IPv6 EXTERNAL_TYPE................................... 64 155 6.8.6.3 IPv6 COMMUNITY_TYPE.................................. 65 156 6.9 Multi-Protocol Route Information TLV Types .................. 66 157 6.9.1 TLV Header Encoding ..................................... 66 158 6.9.2 Wide Metric Encoding .................................... 67 159 6.9.3 Extended Metrics ........................................ 68 160 6.9.3.1 0x00 - NoOp.......................................... 69 161 6.9.3.2 0x01 - Scaled Metric................................. 69 162 6.9.3.3 0x02 - Administrator Tag............................. 70 163 6.9.3.4 0x03 - Community List................................ 70 164 6.9.3.5 0x04 - Jitter........................................ 70 165 6.9.3.6 0x05 - Quiescent Energy.............................. 71 166 6.9.3.7 0x06 - Energy........................................ 71 167 6.9.3.8 0x07 - AddPath....................................... 72 168 6.9.3.8.1 AddPath with IPv4 Next-hop......................... 72 169 6.9.3.8.2 AddPath with IPv6 Next-hop........................ 73 170 6.9.4 Exterior Encoding ....................................... 74 171 6.9.5 Destination Encoding .................................... 74 172 6.9.6 Route Information ....................................... 75 173 6.9.6.1 INTERNAL TYPE........................................ 75 174 6.9.6.2 EXTERNAL TYPE........................................ 75 175 7 Security Considerations.......................................... 76 176 8 IANA Considerations.............................................. 76 177 9 References....................................................... 77 178 9.1 Normative References ........................................ 77 179 9.2 Informative References ...................................... 77 180 10 Acknowledgments................................................. 78 181 1 Introduction 182 This document describes the Enhanced Interior Gateway Routing Protocol 183 (EIGRP), a routing protocol designed and developed by Cisco Systems, 184 Inc. DUAL, the algorithm used to converge the control plane to a 185 single set of loop free paths is based on research conducted at SRI 186 International [3]. The Diffusing Update Algorithm (DUAL) is the 187 algorithm used to obtain loop-freedom at every instant throughout a 188 route computation [2]. This allows all routers involved in a topology 189 change to synchronize at the same time; the routers not affected by 190 topology changes are not involved in the recalculation. This document 191 describes the protocol that implements these functions. 193 2 Terminology 194 The following list describes acronyms and definitions for terms used 195 throughout this document: 197 ACTIVE State 198 The local state of a route on a router triggered by any event that 199 causes all neighbors providing the current least cost path to fail the 200 Feasibility Condition check. A route in Active state is considered 201 unusable. During Active state, the router is actively attempting to 202 compute the least cost loop-free path by explicit coordination with 203 its neighbors using Query and Reply messages. 205 Address Family Identifier (AFI) 206 Identity of the network layer protocol reachability information 207 being advertised [12]. 209 Autonomous System (AS) 210 A collection of routers exchanging routes under the control of one 211 or more network administrators on behalf of a single administrative 212 entity. 214 Base Topology 215 A routing domain representing a physical (non-virtual) view of the 216 network topology consisting of attached devices and network segments 217 EIGRP uses to form neighbor relationships. Destinations exchanged 218 within the Base Topology are identified with a Topology Identifier 219 value of zero (0). 221 Computed Distance (CD) 222 Total distance (metric) along a path from the current router to 223 a destination network through a particular neighbor computed using 224 that neighbor's Reported Distance and the cost of the link between the 225 two routers. Exactly one Computed Distance is computed and maintained 226 per the [Destination, Advertising Neighbor] pair. 228 Diffusing Computation 229 A distributed computation in which a single starting node 230 commences the computation by delegating subtasks of the computation to 231 its neighbors that may in turn recursively delegate sub-subtasks 232 further, including a signaling scheme allowing the starting node to 233 detect that the computation has finished while avoiding false 234 terminations. In DUAL, the task of coordinated updates of routing 235 tables and resulting best path computation is performed as a diffusing 236 computation. 238 Diffusing Update Algorithm (DUAL) 239 A loop-free routing algorithm used with distance vectors or link 240 states that provides a diffused computation of a routing table. It 241 works very well in the presence of multiple topology changes with low 242 overhead. The technology was researched and developed at SRI 243 International [3]. 245 Downstream Router 246 A router that is one or more hops away from the router in question 247 in the direction of the destination. 249 EIGRP 250 Enhanced Interior Gateway Routing Protocol. 252 Feasibility Condition 253 The Feasibility Condition is a sufficient condition used by a 254 router to verify whether a neighboring router provides a loop-free 255 path to a destination. EIGRP uses the Source Node Condition stating 256 that a neighboring router meets the Feasibility Condition if the 257 neighbor's Reported Distance is less than this router's Feasible 258 Distance. 260 Feasible Distance (FD) 261 Defined as the lowest known total metric to a destination from the 262 current router since the last transition from ACTIVE to PASSIVE state. 263 Being effectively a record of the smallest known metric since the last 264 time the network entered the PASSIVE state, the FD is not necessarily 265 a metric of the current best path. Exactly one Feasible Distance is 266 computed per destination network. 268 Feasible Successor 269 A neighboring router that meets the Feasibility Condition for a 270 particular destination, hence providing a guaranteed loop-free path. 272 Neighbor / Peer 273 For a particular router, another router toward which an EIGRP 274 session, also known as adjacency, is established. The ability of two 275 routers to become neighbors depends on their mutual connectivity and 276 compatibility of selected EIGRP configuration parameters. Two 277 neighbors with interfaces connected to a common subnet are known as 278 adjacent neighbors. Two neighbors that are multiple hops apart are 279 known as remote neighbors. 281 PASSIVE state 282 The local state of a route in which at least one neighbor 283 providing the current least cost path passes Feasibility Condition 284 check. A route in PASSIVE state is considered usable and not in need 285 of a coordinated re-computation. 287 Reachability Information (NLRI) 288 Information a router uses to calculate the global routing table to 289 make routing and forwarding decisions. 291 Reported Distance (RD) 292 For a particular destination, the value representing the router's 293 distance to the destination as advertised in all messages carrying 294 routing information. Reported Distance is not equivalent to the 295 current distance of the router to the destination and may be different 296 from it during the process of path re-computation. Exactly one 297 Reported Distance is computed and maintained per destination network. 299 Sub-Topology 300 For a given Base Topology, a sub-topology is characterized by an 301 independent set of routers and links in a network for which EIGRP 302 performs an independent path calculation. This allows each sub- 303 topology to implement class-specific topologies to carry class 304 specific traffic. 306 Successor 307 For a particular destination, a neighboring router that meets the 308 Feasibility Condition and, at the same time, provides the least cost 309 path. 311 Stuck In Active (SIA) 312 A destination that has remained in the ACTIVE State in excess of a 313 predefined time period at the local router (Cisco implements this as 3 314 minutes). 316 Successor Directed Acyclic Graph (SDAG) 317 For a particular destination, a graph defined by routing table 318 contents of individual routers in the topology, such that nodes of 319 this graph are the routers themselves, and a directed edge from router 320 X to router Y exists if and only if router Y is router X's successor. 321 After the network has converged, in the absence of topological 322 changes, SDAG is a tree. 324 Topology Change / Topology Change Event 325 Any event that causes the Computed Distance for a destination 326 through a neighbor to be added, modified, or removed. As an example, 327 detecting a link cost change, receiving any EIGRP message from a 328 neighbor advertising an updated neighbor's Reported Distance 330 Topology Identifier (TID) 331 A number that is used to mark prefixes as belonging to a specific 332 sub-topology. 334 Topology Table 335 A data structure used by EIGRP to store information about every 336 known destination including, but not limited to, network prefix/prefix 337 length, Feasible Distance, Reported Distance of each neighbor 338 advertising the destination, Computed Distance over the corresponding 339 neighbor, and route state. 341 Type, Length, Value (TLV) 342 An encoding format for information elements used in EIGRP messages 343 to exchange information. Each TLV-formatted information element 344 consists of three generic fields: Type identifying the nature of 345 information carried in this element; Length describing the length of 346 the entire TLV triplet; and Value carrying the actual information. The 347 Value field may itself be internally structured; this depends on the 348 actual type of the information element. This format allows for 349 extensibility and backward compatibility. 351 Upstream Router 352 A router that is one or more hops away from the router in 353 question, in the direction of the source of the information. 355 Virtual Routing and Forwarding (VRF) 356 Independent Virtual Private Network (VPN) routing/forwarding 357 tables which co-exist within the same router at the same time. 359 3 The DUAL Diffusing Update Algorithm 360 The Diffusing Update Algorithm (DUAL) constructs least cost paths to 361 all reachable destinations in a network consisting of nodes and edges 362 (routers and links). DUAL guarantees that each constructed path is 363 loop-free at every instant including periods of topology changes and 364 network re-convergence. This is accomplished by all routers, which are 365 affected by a topology change, computing the new best path in a 366 coordinated (diffusing) way and using the Feasibility Condition to 367 verify prospective paths for loop freedom. Routers that are not 368 affected by topology changes are not involved in the recalculation. 369 The convergence time with DUAL rivals that of any other existing 370 routing protocol. 372 3.1 Algorithm Description 373 DUAL is used by EIGRP to achieve fast loop-free convergence with 374 little overhead, allowing EIGRP to provide convergence rates 375 comparable, and in some cases better than, most common link state 376 protocols [10]. Only nodes that are affected by a topology change need 377 to propagate and act on information about the topology change, 378 allowing EIGRP to have good scaling properties, reduced overhead, and 379 lower complexity than many other interior gateway protocols. 381 Distributed routing algorithms are required to propagate information 382 as well as coordinate information among all nodes in the network. 383 Unlike basic Bellman-Ford distance vector protocols that rely on 384 uncoordinated updates when a topology change occurs, DUAL uses a 385 coordinated procedure to involve the affected part of the network into 386 computing a new least cost path, known as a diffusing computation. 387 A diffusing computation grows by querying additional routers for their 388 current Reported Distance to the affected destination, and shrinks by 389 receiving replies from them. Unaffected routers send replies 390 immediately, terminating the growth of the diffusing computation over 391 them. These intrinsic properties cause the diffusing computation to 392 self-adjust in scope and terminate as soon as possible. 394 One attribute of DUAL is its ability to control the point at which the 395 diffusion of a route calculation terminates by managing the 396 distribution of reachability information through the network. 397 Controlling the scope of the diffusing process is accomplished by 398 hiding reachability information through aggregation (summarization), 399 filtering, or other means. This provides the ability to create 400 effective failure domains within a single AS, and allows the network 401 administrator to manage the convergence and processing characteristics 402 of the network. 404 3.2 Route States 405 A route to a destination can be in one of two states, PASSIVE or 406 ACTIVE. These states describe whether the route is guaranteed to be 407 both loop-free and the shortest available (the PASSIVE state), or 408 whether such guarantee cannot be given (the ACTIVE state). 409 Consequently, in PASSIVE state, the router does not perform any route 410 recalculation in coordination with its neighbors because no such 411 recalculation is needed. 413 In ACTIVE state, the router is actively involved in re-computing the 414 least cost loop-free path in coordination with its neighbors. The 415 state is reevaluated and possibly changed every time a topology change 416 is detected. A topology change is any event that causes the Computed 417 Distance to the destination over any neighbor to be added, changed, or 418 removed from EIGRP's topology table. 420 More exactly, the two states are defined as follows: 422 o Passive 423 A route is considered in the Passive state when at least one 424 neighbor that provides the current least total cost path passes the 425 Feasibility Condition check that guarantees loop freedom. A route in 426 the PASSIVE is usable and its next hop is perceived to be a downstream 427 router. 429 o Active 430 A route is considered in the ACTIVE state if neighbors that do 431 not pass the Feasibility Condition check provide lowest cost path, and 432 therefore the path cannot be guaranteed loop free. A route in the 433 ACTIVE state is considered unusable and this router must coordinate 434 with its neighbors in the search for the new loop-free least total 435 cost path. 437 In other words, for a route to be in PASSIVE state, at least one 438 neighbor that provides the least total cost path must be a Feasible 439 Successor. Feasible Successors providing the least total cost path are 440 also called Successors. For a route to be in PASSIVE state, at least 441 one Successor must exist. 443 Conversely, if the path with the least total cost is provided by 444 routers that are not Feasible Successors (and thus not Successors), 445 the route is in the ACTIVE state, requiring re-computation. 447 Notably, for the definition of PASSIVE and ACTIVE states it does not 448 matter if there are Feasible Successors providing a worse-than-least 449 total cost path. While these neighbors are guaranteed to provide a 450 loop free path, that path is potentially not the shortest available. 452 The fact that the least total cost path can be provided by a neighbor 453 that fails the Feasibility Condition check may not be intuitive. 454 However, such situation can occur during topology changes when the 455 current least total cost path fails, and the next least total cost 456 path traverses a neighbor that is not a Feasible Successor. 458 While a router has a route in the ACTIVE state, it must not change its 459 Successor (i.e. modify the current SDAG), nor modify its own Feasible 460 Distance or Reported Distance until the route enters the PASSIVE state 461 again. Any updated information about this route received during ACTIVE 462 state is reflected only in Computed Distances. Any updates to the 463 Successor, Feasible Distance and Reported Distance are postponed until 464 the route returns to PASSIVE state. The state transitions from PASSIVE 465 to ACTIVE and from ACTIVE to PASSIVE are controlled by the DUAL FSM 466 and are described in detail in Section 3.5. 468 3.3 Feasibility Condition 469 The Feasibility Condition is a criterion used to verify loop freedom 470 of a particular path. The Feasibility Condition is a sufficient but 471 not a necessary condition, meaning that every path meeting the 472 Feasibility Condition is guaranteed to be loop-free; however, not all 473 loop-free paths meet the Feasibility condition. 475 The Feasibility Condition is used as an integral part of DUAL 476 operation: Every path selection in DUAL is subject to the Feasibility 477 Condition check. Based on the result of the Feasibility Condition 478 check after a topology change is detected, the route may either remain 479 PASSIVE (if, after the topology change, the neighbor providing the 480 least cost path meets the Feasibility Condition) or it needs to enter 481 the ACTIVE state (if the topology change resulted in none of the 482 neighbors providing the least cost path to meet the Feasibility 483 Condition). 485 The Feasibility Condition is a part of DUAL that allows the diffused 486 computation to terminate as early as possible. Nodes that are not 487 affected by the topology change are not required to perform a DUAL 488 computation and may not be aware a topology change occurred. This can 489 occur in two cases; 491 First, if informed about a topology change, a router may keep a route 492 in PASSIVE State if it is aware of other paths that are downstream 493 towards the destination (routes meeting the Feasibility Condition). A 494 route that meets the Feasibility Condition is determined to be loop- 495 free and downstream along the path between the router and the 496 destination. 498 Second, if informed about a topology change for which it does not 499 currently have reachability information, a router is not required to 500 enter into the ACTIVE state, nor is it required to participate in the 501 DUAL process. 503 In order to facilitate describing the Feasibility Condition, a few 504 definitions are in order. 506 o A Successor for a given route is the next-hop used to forward 507 data traffic for a destination. Typically, the successor is chosen 508 based on the least cost path to reach the destination. 510 o A Feasible Successor is a neighbor that meets the Feasibility 511 Condition. A Feasible Successor is regarded as a downstream neighbor 512 towards the destination but it may not be the least cost path, but 513 could still be used for forwarding data packets in the event equal or 514 unequal cost load sharing was active. A Feasible Successor can become 515 a successor when the current successor becomes unreachable. 517 o The Feasibility Condition is met when a neighbor's advertised 518 cost, (RD) to a destination is less than the Feasible Distance for 519 that destination, or in other words, the Feasibility Condition is met 520 when the neighbor is closer to the destination than the router itself 521 has ever been since the destination has entered the PASSIVE state for 522 the last time. 524 o The Feasible Distance is the lowest distance to the destination 525 since the last time the route went from ACTIVE to PASSIVE state. It 526 should be noted it is not necessarily the current best distance - 527 rather, it is a historical record of the best distance known since the 528 last diffusing computation for the destination has finished. Thus, the 529 value of the Feasible Distance can either be the same as the current 530 best distance, or it can be lower. 532 A neighbor that advertises a route with a cost that does not meet the 533 Feasibility Condition may be upstream and thus cannot be guaranteed to 534 be the next hop for a loop free path. Routes advertised by upstream 535 neighbors are not recorded in the routing table but saved in the 536 topology table. 538 3.4 DUAL Message Types 539 The DUAL algorithm operates with three basic message types, QUERY, 540 UPDATE, and REPLY: 542 o UPDATE - sent to indicate a change in metric or an addition of a 543 destination. 545 o QUERY - sent when Feasibility Condition fails which can happen 546 for reasons like a destination becoming unreachable, or the metric 547 increasing to a value greater than its current Feasible Distance. 549 o REPLY - sent in response to a QUERY or SIA-QUERY 551 In addition to these 3 basic types, two additional sub-types have been 552 added to EIGRP: 554 o SIA-QUERY - sent when a REPLY has not been received within one 555 half the SIA interval (90 seconds as implemented by Cisco) 557 o SIA-REPLY - sent in response to an SIA-QUERY indicating the 558 route is still in ACTIVE state. This response does not stratify the 559 original QUERY, but is only used to indicate the sending neighbor is 560 still in the ACTIVE State for the given destination. 562 When in the PASSIVE State, a received QUERY may be propagated if there 563 is no Feasible Successor found. If a Feasible Successor is found, the 564 QUERY is not propagated and a REPLY is sent for the destination with a 565 metric equal to the current routing table metric. When a QUERY is 566 received from a non-successor in ACTIVE State a REPLY is sent and the 567 QUERY is not propagated. The REPLY for the destination contains a 568 metric equal to the current routing table metric. 570 3.5 DUAL Finite State Machine (FSM) 571 The DUAL finite state machine embodies the decision process for all 572 route computations. It tracks all routes advertised by all neighbors. 573 The distance information, known as a metric, is used by DUAL to select 574 efficient loop free paths. DUAL selects routes to be inserted into a 575 routing table based on Feasible Successors. A successor is a 576 neighboring router used for packet forwarding that has least cost path 577 to a destination that is guaranteed not to be part of a routing loop. 579 When there are no Feasible Successors but there are neighbors 580 advertising the destination, a recalculation must occur to determine a 581 new successor. 583 The amount of time it takes to calculate the route impacts the 584 convergence time. Even though the recalculation is not processor- 585 intensive, it is advantageous to avoid recalculation if it is not 586 necessary. When a topology change occurs, DUAL will test for Feasible 587 Successors. If there are Feasible Successors, it will use any it finds 588 in order to avoid any unnecessary recalculation. 590 The finite state machine, which applies per destination in the 591 topology table, operates independently for each destination. It is 592 true that if a single link goes down, multiple routes may go into 593 ACTIVE State. However, a separate Successor Directed Acyclic Graph 594 (SDAG) is computed for each destination, so loop-free topologies can 595 be maintained for each reachable destination. 597 Figure 1 illustrates the FSM: 599 i Node that is computing route. 600 j Destination node or network. 601 K Any neighbor of node i. 602 oij QUERY origin flag 603 0 = metric increase during ACTIVE State 604 1 = node i originated 605 2 = QUERY from, or link increase to, successor during ACTIVE State 606 3 = QUERY originated from successor. 607 rijk REPLY status flag for each neighbor k for destination j, 608 1 = awaiting REPLY, 609 0 = received REPLY. 610 lik = the link connecting node i to neighbor k. 612 +------------+ +-----------+ 613 | \ / | 614 | \ / | 615 | +=================================+ | 616 | | | | 617 |(1)| Passive |(2)| 618 +-->| |<--+ 619 +=================================+ 620 ^ | ^ ^ ^ | 621 (14)| |(15)| |(13)| | 622 | (4)| |(16)| | (3)| 623 | | | | | +------------+ 624 | | | | | \ 625 +-------+ + + | +-------------+ \ 626 / / / | \ \ 627 / / / +----+ \ \ 628 | | | | | | 629 | v | | | v 630 +==========+(11) +==========+ +==========+(12) +==========+ 631 | Active |---->| Active |(5) | Active |---->| Active | 632 | | (9)| |---->| | (10)| | 633 | Oij=0 |<----| Oij=1 | | Oij=2 |<----| Oij=3 | 634 +--| | +--| | +--| | +--| | 635 | +==========+ | +==========+ | +==========+ | +==========+ 636 | ^ |(5) | ^ | ^ ^ | ^ 637 | | +-----|------|---------|----+ | | | 638 +------+ +------+ +---------+ +---------+ 639 (6,7,8) (6,7,8) (6,7,8) (6,7,8) 641 Figure 1 - DUAL Finite State Machine 643 The following describes in detail the state/event/action transitions 644 of the DUAL FSM. For all steps, the topology table is updated with the 645 new metric information from either; QUERY, REPLY, or UPDATE received. 647 (1) A QUERY is received from a neighbor that is not the current 648 successor. The route is currently in PASSIVE State. As the Successor 649 is not affected by the QUERY, and a Feasible Successor exists, the 650 route remains in PASSIVE State. Since a Feasible Successor exists, a 651 REPLY MUST be sent back to the originator of the QUERY. Any metric 652 received in the QUERY from that neighbor is recorded in the topology 653 table and FC is run to check for any change to current successor. 655 (2) A directly connected interface changes state (connects, 656 disconnects, or changes metric), or similarly an UPDATE or QUERY has 657 been received with a metric change for an existing destination, the 658 route will stay in the PASSIVE State if the current successor is not 659 affected by the change, or it is no longer reachable and there is a 660 Feasible Successor. In either case, an UPDATE is sent with the new 661 metric information if it has changed. 663 (3) A QUERY was received from a neighbor who is the current successor 664 and no Feasible Successors exist. The route for the destination goes 665 into ACTIVE State. A QUERY is sent to all neighbors on all interfaces 666 that are not split horizon. Split horizon takes effect for a query or 667 update from the successor it is using for the destination in the 668 query. The QUERY origin flag is set to indicate the QUERY originated 669 from a neighbor marked as successor for route. The REPLY status flag 670 is set for all neighbors to indicate outstanding replies. 672 (4) A directly connected link has gone down or its cost has increased, 673 or an UPDATE has been received with a metric increase. The route to 674 the destination goes to ACTIVE State if there are no Feasible 675 Successors found. A QUERY is sent to all neighbors on all interfaces. 676 The QUERY origin flag is to indicate that the router originated the 677 QUERY. The REPLY status flag is set to 1 for all neighbors to indicate 678 outstanding replies. 680 (5) While a route for a destination is in ACTIVE State, and a QUERY is 681 received from the current successor, the route remains in ACTIVE 682 State. The QUERY origin flag is set to indicate that there was another 683 topology change while in ACTIVE State. This indication is used so new 684 Feasible Successors are compared to the metric which made the route go 685 to ACTIVE State with the current successor. 687 (6) While a route for a destination is in ACTIVE State and a QUERY is 688 received from a neighbor that is not the current successor, a REPLY 689 should be sent to the neighbor. The metric received in the QUERY 690 should be recorded. 692 (7) If a link cost changes, or an UPDATE with a metric change is 693 received in ACTIVE State from a non-successor, the router stays in 694 ACTIVE State for the destination. The metric information in the UPDATE 695 is recorded. When a route is in the ACTIVE State, neither a QUERY nor 696 UPDATE are ever sent. 698 (8) If a REPLY for a destination, in ACTIVE State, is received from a 699 neighbor or the link between a router and the neighbor fails, the 700 router records that the neighbor replied to the QUERY. The REPLY 701 status flag is set to 0 to indicate this. The route stays in ACTIVE 702 State if there are more replies pending because the router has not 703 heard from all neighbors. 705 (9) If a route for a destination is in ACTIVE State, and a link fails 706 or a cost increase occurred between a router and its successor, the 707 router treats this case like it has received a REPLY from its 708 successor. When this occurs after the router originates a QUERY, it 709 sets the QUERY origin flag to indicate that another topology change 710 occurred in ACTIVE State. 712 (10) If a route for a destination is in ACTIVE State, and a link fails 713 or a cost increase occurred between a router and its successor, the 714 router treats this case like it has received a REPLY from its 715 successor. When this occurs after a successor originated a QUERY, the 716 router sets the QUERY origin flag to indicate that another topology 717 change occurred in ACTIVE State. 719 (11) If a route for a destination is in ACTIVE State, the cost of the 720 link through which the successor increases, and the last REPLY was 721 received from all neighbors, but there is no Feasible Successor, the 722 route should stay in ACTIVE State. A QUERY is sent to all neighbors. 723 The QUERY origin flag is set to 1. 725 (12) If a route for a destination is in ACTIVE State because of a 726 QUERY received from the current successor, and the last REPLY was 727 received from all neighbors, but there is no Feasible Successor, the 728 route should stay in ACTIVE State. A QUERY is sent to all neighbors. 729 The QUERY origin flag is set to 3. 731 (13) Received replies from all neighbors. Since the QUERY origin flag 732 indicates the successor originated the QUERY, it transitions to 733 PASSIVE State and sends a REPLY to the old successor. 735 (14) Received replies from all neighbors. Since the QUERY origin flag 736 indicates a topology change to the successor while in ACTIVE State, it 737 need not send a REPLY to the old successor. When the Feasibility 738 Condition is met, the route state transitions to PASSIVE. 740 (15) Received replies from all neighbors. Since the QUERY origin flag 741 indicates either the router itself originated the QUERY or FC was not 742 satisfied with the replies received in ACTIVE state, FD is reset to 743 infinite value and the minimum of all the reported metrics is chosen 744 as FD and route transitions back to PASSIVE state. A REPLY is sent to 745 the old-successor if Oij flags indicate that there was a QUERY from 746 successor. 748 (16) If a route for a destination is in ACTIVE State because of a 749 QUERY received from the current successor or there was an increase in 750 Distance while in ACTIVE state, the last REPLY was received from all 751 neighbors, and a Feasible Successor exists for the destination, the 752 route can go into PASSIVE State and a REPLY is sent to successor if 753 Oij indicates that QUERY was received from the successor. 755 3.6 DUAL Operation - Example Topology 756 The following topology (Figure 2) will be used to provide an example 757 of how DUAL is used to reroute after a link failure. Each node is 758 labeled with its costs to destination N. The arrows indicate the 759 successor (next-hop) used to reach destination N. The least cost path 760 is selected. 761 N 762 | 763 (1)A ---<--- B(2) 764 | | 765 ^ | 766 | | 767 (2)D ---<--- C(3) 769 Figure 2 - Stable Topology 771 In the case where the link between A and D fails (Figure 3); 773 N N 774 | | 775 A ---<--- B A ---<--- B 776 | | | | 777 X | ^ | 778 | | | | 779 D ---<--- C D ---<--- C 780 Q-> <-R 782 N 783 | 784 (1)A ---<--- B(2) 785 | 786 ^ 787 | 788 (4)D --->--- C(3) 790 Figure 3 - Link between A and D fails 792 Only observing destination provided by node N, D enters the ACTIVE 793 State and sends a QUERY to all its neighbors, in this case node C. 794 C determines that it has a Feasible Successor and replies 795 immediately with metric 3. 796 C changes its old successor of D to its new single successor B and 797 the route to N stays in PASSIVE State. 798 D receives the REPLY and can transition out of ACTIVE State since 799 it received replies from all its neighbors. 800 D now has a viable path to N through C. 801 D selects C as its successor to reach node N with a cost of 4. 803 Notice that node A and B were not involved in the recalculation since 804 they were not affected by the change. 806 Let's consider the situation in Figure 4, where Feasible Successors 807 may not exist. If the link between node A and B fails, B goes into 808 ACTIVE State for destination N since it has no Feasible Successors. 809 Node B sends a QUERY to node C. C has no Feasible Successors, so it 810 goes active for destination N and since C has no neighbors, it replies 811 to the QUERY, deletes the destination, and returns to the PASSIVE 812 State for the unreachable route. As C removes the (now unreachable) 813 destination from its table, C sends REPLY to its old successor. B 814 receives this REPLY from C, and determines this is the last REPLY it 815 is waiting on before determining what the new state of the route 816 should be; on receiving this REPLY, B deletes the route to N from its 817 routing table. 819 Since B was the originator of the initial QUERY it does not have to 820 send a REPLY to its old successor (it would not be able to any ways, 821 because the link to its old successor is down). Note that nodes A and 822 D were not involved in the recalculation since their successors were 823 not affected. 825 N N 826 | | 827 (1)A ---<--- B(2) A ------- B Q 828 | | | | |^ ^ 829 ^ ^ ^ | v| | 830 | | | | | | 831 (2)D C(3) D C ACK R 833 Figure 4 834 No Feasible Successors when link between A and B fails 836 4 EIGRP Packets 837 EIGRP uses 5 different packet types to handle session management and 838 pass DUAL Message types: 840 HELLO Packets (includes ACK) 841 QUERY Packets (includes SIA-Query) 842 REPLY Packets (includes SIA-Reply) 843 REQUEST Packets 844 UPDATE Packets 846 EIGRP packets are directly encapsulated into a network layer protocol, 847 such as IPv4 or IPv6. While EIGRP is capable of using additional 848 encapsulation (such as AppleTalk, IPX, etc.) no further encapsulation 849 is specified in this document. 851 Support for network layer protocol fragmentation is not supported, and 852 EIGRP will attempt to avoid a maximum size packets that exceed the 853 interface MTU by sending multiple packets which are less than or equal 854 to MTU sized packets. 856 Each packet transmitted will use either multicast or unicast network 857 layer destination addresses. When multicast addresses are used a 858 mapping for the data link multicast address (when available) must be 859 provided. The source address will be set to the address of the sending 860 interface, if applicable. 862 The following network layer multicast addresses; and associated data 863 link multicast addresses; 864 IPv4 "IGRP Routers" [13] 865 IPv6 "EIGRP Routers" [14] 867 Will be used on multicast capable media, and will be media independent 868 for unicast addresses. Network layer addresses will be used and the 869 mapping to media addresses will be achieved by the native protocol 870 mechanisms. 872 4.1 UPDATE Packets 873 UPDATE packets carry the DUAL UPDATE message type, and are used to 874 convey information about destinations and the reachability of those 875 destinations. When a new neighbor is discovered, unicast UPDATE 876 packets are used to transmit a full table to the new neighbor, so the 877 neighbor can build up its topology table. In normal operation (other 878 than neighbor startup such as a link cost changes), UPDATE packets are 879 multicast. UPDATE packets are always transmitted reliably. Each TLV 880 destination will be processed individually through the DUAL state 881 machine. 883 4.2 QUERY Packets 884 A QUERY packet carries the DUAL QUERY message type and is sent by a 885 router to advertise that a route is in ACTIVE State and the originator 886 is requesting alternate path information from its neighbors. An 887 infinite metric is encoded by setting the Delay part of the metric to 888 its maximum value. 890 If there is a topology change that causes multiple destinations to be 891 marked ACTIVE, EIGRP will build one or more QUERY packet for all 892 destinations present. The state of each route is recorded 893 individually, so a responding QUERY or REPLY need not contain all the 894 same destinations in a single packet. Since EIGRP uses a reliable 895 transport mechanism, route QUERY packets are also guaranteed be 896 reliably delivered. 898 When a QUERY packet is received, each destination will trigger a DUAL 899 event and the state machine will run individually for each route. Once 900 the entire original QUERY packet is processed, then a REPLY or SIA- 901 REPLY will be sent with the latest information. 903 4.3 REPLY Packets 904 A REPLY packet carries the DUAL REPLY message type and will be sent in 905 response to a QUERY or SIA-QUERY packet. The REPLY packet will include 906 a TLV for each destination and the associated vector metric in its own 907 topology table. 909 The REPLY packet is sent after the entire received QUERY packet is 910 processed. When a REPLY packet is received, there is no reason to 911 process the packet before an acknowledgment is sent. Therefore, an 912 acknowledgment is sent immediately and then the packet is processed. 913 The sending of the acknowledgement is accomplished either by sending 914 an ACK packet, or piggybacked the acknowledgment onto another packet 915 already being transmitted. 917 Each TLV destination will be processed individually through the DUAL 918 state machine. When a QUERY is received for a route that doesn't exist 919 in our topology table, a REPLY with infinite metric is sent and an 920 entry in the topology table is added with the metric in the QUERY if 921 the metric is not an infinite value. 923 If a REPLY for a designation not in the Active State, or not in the 924 topology table, EIGRP will acknowledge the packet, and discard the 925 REPLY. 927 4.4 Exception Handling 928 4.4.1 Active Duration (Stuck-in-Active) 929 When an EIGRP router transitions to ACTIVE state for a particular 930 destination a QUERY is sent to a neighbor and the ACTIVE timer is 931 started to limit the amount of time a destination may remain in an 932 ACTIVE State. 934 A route is regarded as Stuck-In-Active (SIA) when it does not receive 935 a REPLY within a preset time. This time interval is broken into two 936 equal periods following the QUERY, and up to 3 additional "busy" 937 periods in which an SIA-QUERY packet is sent for the destination. 939 This process is begun when a router sends a QUERY to its neighbor. 940 After one half the SIA time interval (default implementation is 90 941 seconds), the router will send an SIA-QUERY; this must be replied to 942 with either a REPLY or SIA-REPLY. Any neighbor which fails to send 943 either a REPLY or SIA-REPLY with-in one-half the SIA interval will 944 result in the neighbor being deemed to be "stuck" in the active state. 946 Cisco also limits the number of SIA-REPLY messages allowed to three. 947 Once the timeout occurs after the third SIA-REPLY with the neighbor 948 remaining in an ACTIVE State (as noted in the SIA-Reply message), the 949 neighbor being deemed to be "stuck" in the active state. 951 If the SIA state is declared, DUAL may take one of two actions; 952 a) Delete the route from that neighbor, acting as if the neighbor 953 had responded with an unreachable REPLY message from the neighbor. 955 b) Delete all routes from that neighbor and reset the adjacency 956 with that neighbor, acting as if the neighbor had responded with an 957 unreachable message for all routes. 959 Implementation note: Cisco currently implements option (b). 961 4.4.1.1 SIA-QUERY 962 When a QUERY is still outstanding and awaiting a REPLY from a 963 neighbor, there is insufficient information to determine why a REPLY 964 has not been received. A lost packet, congestion on the link, or a 965 slow neighbor could cause a lack of REPLY from a downstream neighbor. 967 In order to attempt to ascertain if the neighboring device is still 968 attempting to converge on the active route, EIGRP may send an SIA- 969 QUERY packet to the active neighbor(s). This enables an EIGRP router 970 to determine if there is a communication issue with the neighbor, or 971 it is simply still attempting to converge with downstream routers. 973 By sending an SIA-QUERY, the originating router may extend the 974 effective active time by resetting the ACTIVE timer which has been 975 previously set, thus allowing convergence to continue so long as 976 neighbor devices successfully communicate that convergence is still 977 underway. 979 The SIA-QUERY packet SHOULD be sent on a per-destination basis at one- 980 half of the ACTIVE timeout period. Up to three SIA-QUERY packets for a 981 specific destination may be sent, each at a value of one-half the 982 ACTIVE time, so long as each are successfully acknowledged and met 983 with an SIA-REPLY. 985 Upon receipt of an SIA-QUERY packet, an EIGRP router should first send 986 an ACK and then continue to process the SIA-QUERY information. The 987 QUERY is sent on a per-destination basis at approximately one-half the 988 active time. 990 If the EIGRP router is still active for the destination specified in 991 the SIA-QUERY, the router should respond to the originator with the 992 SIA-REPLY indicating that active processing for this destination is 993 still underway by setting the ACTIVE flag in the packet upon response. 995 If the router receives an SIA-QUERY referencing a destination for 996 which it has not received the original QUERY, the router should treat 997 the packet as though it was a standard QUERY: 999 1) Acknowledge the receipt of the packet 1000 2) Send a REPLY if a Successor exists 1001 3) If the SIA-QUERY is from the successor, transition to the 1002 ACTIVE state if and only if feasibility-condition fails 1003 and send an SIA-REPLY with the ACTIVE bit set 1005 4.4.1.2 SIA-REPLY 1006 An SIA-REPLY packet is the corresponding response upon receipt of an 1007 SIA-QUERY from an EIGRP neighbor. The SIA-REPLY packet will include a 1008 TLV for each destination and the associated metric for which is stored 1009 in its own routing table. The SIA-REPLY packet is sent after the 1010 entire received SIA-QUERY packet is processed. 1012 If the EIGRP router is still ACTIVE for a destination, the SIA-REPLY 1013 packet will be sent with the ACTIVE bit set. This confirms for the 1014 neighbor device that the SIA-QUERY packet has been processed by DUAL 1015 and that the router is still attempting to resolve a loop-free path 1016 (likely awaiting responses to its own QUERY to downstream neighbors). 1018 The SIA-REPLY informs the recipient that convergence is complete or 1019 still ongoing; it is an explicit notification that the router is still 1020 actively engaged in the convergence process. This allows the device 1021 that sent the SIA-QUERY to determine whether it should continue to 1022 allow the routes that are not converged to be in the ACTIVE state, or 1023 if it should reset the neighbor relationship and flush all routes 1024 through this neighbor. 1026 5 EIGRP Protocol Operation 1027 EIGRP has four basic components: 1028 o Finite State Machine 1029 o Reliable Transport Protocol 1030 o Neighbor Discovery/Recovery 1031 o Route Management 1033 5.1 Finite State Machine 1034 The detail of DUAL, the State Machine used by EIGRP, is covered in 1035 Section 0 1037 5.2 Reliable Transport Protocol 1038 The reliable transport is responsible for guaranteed, ordered delivery 1039 of EIGRP packets to all neighbors. It supports intermixed transmission 1040 of multicast and unicast packets. Some EIGRP packets must be 1041 transmitted reliably and others need not. For efficiency, reliability 1042 is provided only when necessary. 1044 For example, on a multi-access network that has multicast 1045 capabilities, such as Ethernet, it is not necessary to send HELLOs 1046 reliably to all neighbors individually. EIGRP sends a single multicast 1047 HELLO with an indication in the packet informing the receivers that 1048 the packet need not be acknowledged. Other types of packets, such as 1049 UPDATE packets, require acknowledgment and this is indicated in the 1050 packet. The reliable transport has a provision to send multicast 1051 packets quickly when there are unacknowledged packets pending. This 1052 helps ensure that convergence time remains low in the presence of 1053 varying speed links. 1055 The DUAL Algorithm assumes there is lossless communication between 1056 devices and thus must rely upon the transport protocol to guarantee 1057 that messages are transmitted reliably. EIGRP implements the Reliable 1058 Transport Protocol to ensure ordered delivery and acknowledgement of 1059 any messages requiring reliable transmission. State variables such as 1060 a received sequence number, acknowledgment number, and transmission 1061 queues MUST be maintained on a per neighbor basis. 1063 The following sequence number rules must be met for the reliable EIGRP 1064 protocol to work correctly: 1066 o A sender of a packet includes its global sequence number 1067 in the sequence number field of the fixed header. The sequence 1068 number wraps around to one when the maximum value is exceeded 1069 (sequence number zero is reserved for unreliable transmission). 1070 The sender includes the receivers sequence number in the 1071 acknowledgment number field of the fixed header. 1072 o Any packets that do not require acknowledgment must be 1073 sent with a sequence number of 0. 1074 o Any packet that has an acknowledgment number of zero (0) 1075 indicates that sender is not expecting to explicitly 1076 acknowledging delivery. Otherwise, it is acknowledging 1077 a single packet. 1078 o Packets that are network layer multicast must contain 1079 acknowledgment number of 0. 1081 When a router transmits a packet, it increments its sequence number 1082 and marks the packet as requiring acknowledgment by all neighbors on 1083 the interface for which the packet is sent. When individual 1084 acknowledgments are unicast addressed by the receivers to the sender 1085 with the acknowledgment number equal to the packets sequence number, 1086 the sender SHALL clear the pending acknowledgement requirement for the 1087 packet from the respective neighbor. 1089 If the required acknowledgement is not received for the packet, it 1090 MUST be retransmitted. Retransmissions will occur for a maximum of 5 1091 seconds. This retransmission for each packet is tried 16 times after 1092 which if there is no ACK, the neighbor relationship is reset with that 1093 peer which didn't send the ACK. 1095 The protocol has no explicit windowing support. A receiver will 1096 acknowledge each packet individually and will drop packets that are 1097 received out of order. 1099 Implementers note: The exception to this occurs if a duplicate packet 1100 is received, and the acknowledgement for the original packet has been 1101 scheduled for transmission, but not yet sent. In this case EIGRP will 1102 not send an acknowledgement for the duplicate packet, and the queued 1103 acknowledgement will acknowledge both the original and duplicate 1104 packet 1106 Duplicate packets are also discarded upon receipt. Acknowledgments are 1107 not accumulative. Therefore, an ACK with a non-zero sequence number 1108 acknowledges a single packet. 1110 There are situations when multicast and unicast packets are 1111 transmitted close together on multi-access broadcast capable networks. 1112 The reliable transport mechanism MUST assure that all multicasts are 1113 transmitted in order as well as not mixing the order among unicasts 1114 and multicast packets. The reliable transport provides a mechanism to 1115 deliver multicast packets in order to some receivers quickly, while 1116 some receivers have not yet received all unicast or previously sent 1117 multicast packets. The SEQUENCE_TYPE TLV in HELLO packets achieves 1118 this. This will be explained in more detail in this section. 1120 Figure 5 illustrates the reliable transport protocol on point-to-point 1121 links. There are two scenarios that may occur, an UPDATE initiated 1122 packet exchange, or a QUERY initiated packet exchange. 1124 This example will assume no packet loss. 1126 Router A Router B 1128 An Example UPDATE Exchange 1129 <---------------- 1130 UPDATE (multicast) 1131 A receives packet SEQ=100, ACK=0 1132 Add Packet to A's retransmit list 1133 ----------------> 1134 ACK (unicast) 1135 SEQ=0, ACK=100 Receives ACK 1136 Process UPDATE Delete Packet from A's retransmit list 1138 An Example QUERY Exchange 1139 <---------------- 1140 QUERY (multicast) 1141 A receives packet SEQ=101, ACK=0 1142 Process QUERY Add Packet to A's retransmit list 1144 ----------------> 1145 REPLY (unicast) 1146 SEQ=201, ACK=101 Process ACK 1147 Delete Packet from A's retransmit 1148 list 1149 Process REPLY pkt 1150 <---------------- 1151 ACK (unicast) 1152 A receives packet SEQ=0, ACK=201 1154 Figure 5 - Reliable Transfer on point-to-point links 1156 The UPDATE exchange sequence requires UPDATE packets sent to be 1157 delivered reliably. The UPDATE packet transmitted contains a sequence 1158 number that is acknowledged by a receipt of an ACK packet. If the 1159 UPDATE or the ACK packet is lost on the network, the UPDATE packet 1160 will be retransmitted. 1162 This example will assume there is heavy packet loss on a network. 1164 Router A Router B 1165 <---------------- 1166 UPDATE (multicast) 1167 A receives packet SEQ=100, ACK=0 1168 Add Packet to A's retransmit list 1169 ----------------> 1170 ACK (unicast) 1171 SEQ=0, ACK=100 Receives ACK 1172 Process Update Delete Packet from A's retransmit list 1174 <--/LOST/-------------- 1175 UPDATE (multicast) 1176 SEQ=101, ACK=0 1177 Add Packet to A's retransmit list 1179 Retransmit Timer Expires 1180 <---------------- 1181 Retransmit UPDATE (unicast) 1182 SEQ=101, ACK=0 1183 Keeps packet on A's retransmit list 1184 ----------------> 1185 ACK (unicast) 1186 SEQ=0, ACK=101 Receives ACK 1187 Process Update Delete Packet from A's retransmit list 1189 Figure 6 1190 Reliable Transfer on lossy point-to-point links 1192 Reliable delivery on multi-access LANs works in a similar fashion to 1193 point-to-point links. The initial packet is always multicast and 1194 subsequent retransmissions are unicast addressed. The acknowledgments 1195 sent are always unicast addressed. Figure 7 shows an example with 4 1196 routers on an Ethernet. 1198 Router B -----------+ 1199 | 1200 Router C -----------+------------ Router A 1201 | 1202 Router D -----------+ 1204 An Example UPDATE Exchange 1205 <---------------- 1206 A send UPDATE (multicast) 1207 SEQ=100, ACK=0 1208 Add Packet to B's retransmit list 1209 Add Packet to C's retransmit list 1210 Add Packet to D's retransmit list 1212 ----------------> 1213 B sends ACK (unicast) 1214 SEQ=0, ACK=100 Receives ACK 1215 Process Update Delete Packet from B's retransmit list 1217 ----------------> 1218 C sends ACK (unicast) 1219 SEQ=0, ACK=100 Receives ACK 1220 Process Update Delete Packet from C's retransmit list 1222 ----------------> 1223 D sends ACK (unicast) 1224 SEQ=0, ACK=100 Receives ACK 1225 Process Update Delete Packet from D's retransmit list 1226 An Example QUERY Exchange 1228 <---------------- 1229 A send UPDATE (multicast) 1230 SEQ=101, ACK=0 1231 Add Packet to B's retransmit list 1232 Add Packet to C's retransmit list 1233 Add Packet to D's retransmit list 1235 ----------------> 1236 B send REPLY (unicast) <---------------- 1237 SEQ=511, ACK=101 A sends ACK (unicast to B) 1238 Process Update SEQ=0, ACK=511 1239 Delete Packet from B's retransmit list 1241 ----------------> 1242 C send REPLY (unicast) <---------------- 1243 SEQ=200, ACK=101 A sends ACK (unicast to C) 1244 Process Update SEQ=0, ACK=200 1245 Delete Packet from C's retransmit list 1247 ----------------> 1248 D send REPLY (unicast) <---------------- 1249 SEQ=11, ACK=101 A sends ACK (unicast to D) 1250 Process Update SEQ=0, ACK=11 1251 Delete Packet from D's retransmit list 1253 Figure 7 1254 Reliable Transfer on Multi-Access Links 1256 And finally, a situation where numerous multicast and unicast packets 1257 are sent close together in a multi-access environment is illustrated 1258 in Figure 9. 1260 Router B -----------+ 1261 | 1262 Router C -----------+------------ Router A 1263 | 1264 Router D -----------+ 1266 <---------------- 1267 A send UPDATE (multicast) 1268 SEQ=100, ACK=0 1269 ---------------/LOST/-> Add Packet to B's retransmit list 1270 B send ACK (unicast) Add Packet to C's retransmit list 1271 SEQ=0, ACK=100 Add Packet to D's retransmit list 1273 ----------------> 1274 C sends ACK (unicast) 1275 SEQ=0, ACK=100 Delete Packet from C's retransmit list 1277 ----------------> 1278 D sends ACK (unicast) 1279 SEQ=0, ACK=100 Delete Packet from D's retransmit list 1280 <---------------- 1281 A send HELLO (multicast) 1282 SEQ=0, ACK=0, SEQ_TLV listing B 1284 B receives Hello, does not set CR-Mode 1285 C receives Hello, sets CR-Mode 1286 D receives Hello, sets CR-Mode 1288 <---------------- 1289 A send UPDATE (multicast) 1290 SEQ=101, ACK=0, CR-Flag=1 1291 ---------------/LOST/-> Add Packet to B's retransmit list 1292 B send ACK (unicast) Add Packet to C's retransmit list 1293 SEQ=0, ACK=100 Add Packet to D's retransmit list 1295 B ignores UPDATE 101 because CR-Flag 1296 is set and it is not in CR-Mode 1298 ----------------> 1299 C sends ACK (unicast) 1300 SEQ=0, ACK=101 1302 ----------------> 1303 D sends ACK (unicast) 1304 SEQ=0, ACK=101 1305 <---------------- 1306 A resends UPDATE (unicast to B) 1307 SEQ=100, ACK=0 1308 B Packet duplicate 1310 ---------------> 1311 B sends ACK (unicast) A removes pkt from retransmit list 1312 SEQ=0, ACK=100 1313 <---------------- 1314 A resends UPDATE (unicast to B) 1315 SEQ=101, ACK=0 1317 ---------------> 1318 B sends ACK (unicast) A removes pkt from retransmit list 1319 SEQ=0, ACK=101 1321 Figure 9 1323 Initially Router-A sends a multicast addressed UPDATE packet on the 1324 LAN. B and C receive it and send acknowledgments. Router-B receives 1325 the UPDATE but the acknowledgment sent is lost on the network. Before 1326 the retransmission timer for Router-B's packet expires, there is an 1327 event that causes a new multicast addressed UPDATE to be sent. 1329 Router-A detects that there is at least one neighbor on the interface 1330 with a full queue. Therefore, it MUST signal that neighbor to not 1331 receive the next packet or it would receive the retransmitted packet 1332 out of order. If all neighbors on the interface have a full queue, 1333 then EIGRP should reschedule the transmission of the UPDATE once the 1334 queues are no longer full. 1336 Router-A builds a HELLO packet with a SEQUENCE_TYPE TLV indicating all 1337 the neighbors that have full queues. In this case, the only neighbor 1338 address in the list is Router-B. The HELLO packet is sent via 1339 multicast unreliably out the interface. 1341 Router-C and Router-D process the SEQUENCE_TYPE TLV by looking for its 1342 own address in the list. If not found, they put themselves in 1343 Conditionally Received (CR-mode) mode. 1345 Router-B does not find its address in the SEQUENCE TLV peer list, so 1346 it enters CR-mode. Packets received by Router-B with the CR-flag MUST 1347 be discarded and not acknowledged. 1349 Later, Router-A will unicast transmit both packets 100 and 101 1350 directly to Router-B. Router-B already has 100 so it discards and 1351 acknowledges it. 1353 Router-B then accepts and acknowledges packet 101. Once an 1354 acknowledgement is received, Router-A can remove both packets from 1355 Router-B's transmission list. 1357 5.2.1 Bandwidth on Low-Speed Links 1358 By default, EIGRP limits itself to using no more than 50% of the 1359 bandwidth reported by an interface when determining packet-pacing 1360 intervals. If the bandwidth does not match the physical bandwidth (the 1361 network architect may have put in an artificially low or high 1362 bandwidth value to influence routing decisions), EIGRP may: 1364 1. Generate more traffic than the interface can handle, possibly 1365 causing drops, thereby impairing EIGRP performance. 1367 2. Generate a lot of EIGRP traffic that could result in little 1368 bandwidth remaining for user data. To control such transmissions an 1369 interface-pacing timer is defined for the interfaces on which EIGRP is 1370 enabled. When a pacing timer expires, a packet is transmitted out on 1371 that interface. 1373 5.3 Neighbor Discovery/Recovery 1374 Neighbor Discovery/Recovery is the process that routers use to 1375 dynamically learn of other routers on their directly attached 1376 networks. Routers MUST also discover when their neighbors become 1377 unreachable or inoperative. This process is achieved with low overhead 1378 by periodically sending small HELLO packets. As long as any packets 1379 are received from a neighbor, the router can determine that neighbor 1380 is alive and functioning. Only after a neighbor router is considered 1381 operational can the neighboring routers exchange routing information. 1383 5.3.1 Neighbor Hold Time 1384 Each router keeps state information about adjacent neighbors. When 1385 newly discovered neighbors are learned the address, interface, and 1386 hold time of the neighbor is noted. When a neighbor sends a HELLO, it 1387 advertises its Hold Time. The Hold Time is the amount of time a router 1388 treats a neighbor as reachable and operational. In addition to the 1389 HELLO packet, if any packet is received within the hold time period, 1390 then the Hold Time period will be reset. When the Hold Time expires, 1391 DUAL is informed of the topology change. 1393 5.3.2 HELLO Packets 1394 When an EIGRP router is initialized, it will start sending HELLO 1395 packets out any interface on which EIGRP is enabled. HELLO packets, 1396 when used for neighbor discovery, are normally sent multicast 1397 addressed. The HELLO packet will include the configured EIGRP metric 1398 K-values. Two routers become neighbors only if the K-values are the 1399 same. This enforces that the metric usage is consistent throughout the 1400 Internet. Also included in the HELLO packet, is a Hold Time value. 1401 This value indicates to all receivers the length of time in seconds 1402 that the neighbor is valid. The default Hold Time will be 3 times the 1403 HELLO interval. HELLO packets will be transmitted every 5 seconds (by 1404 default). There may be a configuration command that controls this 1405 value and therefore changes the Hold Time. HELLO packets are not 1406 transmitted reliably so the sequence number should be set to 0. 1408 5.3.3 UPDATE Packets 1409 When a router detects a new neighbor by receiving a HELLO packet from 1410 a neighbor not presently known, it will send a unicast UPDATE packet 1411 to the neighbor with no routing information (the NULL UPDATE packet). 1412 The initial NULL UPDATE packet sent MUST have the INIT-flag set and 1413 containing no topology information. 1415 Implementation note: The use of the NULL UPDATE is used to ensure bi- 1416 directional UNICAST packet delivery as the NULL UPDATE and the ACK are 1417 both sent unicast. Additional UPDATE packets cannot be sent until the 1418 initial NULL UPDATE packet is acknowledged. 1420 The INIT-flag instructs the neighbor to advertise its routes, and is 1421 also useful when a neighbor goes down and comes back up before the 1422 router detects it went down. In this case, the neighbor needs new 1423 routing information. The INIT-Flag informs the router to send it. 1425 Implementation note: When a router sends an UPDATE with the INIT-Flag 1426 set, and without the Restart Flag (RS) set in the header, the 1427 receiving neighbor must also send an UPDATE with the INIT-Flag. 1428 Failure to do so will result in a Cisco device posting a stuck in 1429 INIT state" error and discards subsequent. 1431 5.3.4 Initialization Sequence 1432 Router A Router B 1433 (just booted) (up and running) 1435 (1)----------------> 1436 HELLO (multicast) <---------------- (2) 1437 SEQ=0, ACK=0 HELLO (multicast) 1438 SEQ=0, ACK=0 1440 <---------------- (3) 1441 UPDATE (unicast) 1442 SEQ=10, ACK=0, INIT 1443 (4)----------------> UPDATE 11 is queued 1444 UPDATE (unicast) 1445 SEQ=100, ACK=10, INIT <---------------- (5) 1446 UPDATE (unicast) 1447 SEQ=11, ACK=100 1448 All UPDATES sent 1449 (6)--------------/lost/-> 1450 ACK (unicast) 1451 SEQ=0, ACK=11 1452 (5 seconds later) 1453 <---------------- (7) 1454 Duplicate received, UPDATE (unicast) 1455 Packet discarded SEQ=11, ACK=100 1456 (8)---------------> 1457 ACK (unicast) 1458 SEQ=0, ACK=11 1460 Figure 9 - Initialization Sequence 1462 (1) Router A sends multicast HELLO and Router B discovers it. 1464 (2) Router B sends an expedited HELLO and starts the process of 1465 sending its topology table to Router A. In addition, Router B sends 1466 the NULL UPDATE packet with the INIT-Flag. The second packet is 1467 queued, but cannot be sent until the first is acknowledged. 1469 (3) Router A receives first UPDATE packet and processes it as a DUAL 1470 event. If the UPDATE contains topology information, the packet will be 1471 process and stored in topology table. Sends its first and only UPDATE 1472 packet with an accompanied ACK. 1474 (4) Router B receives UPDATE packet 100 from Router A. Router B can 1475 dequeue packet 10 from A's transmission list since the UPDATE 1476 acknowledged 10. It can now send UPDATE packet 11 and with an 1477 acknowledgment of Router A's UPDATE. 1479 (5) Router A receives the last UPDATE packet from Router B and 1480 acknowledges it. The acknowledgment gets lost. 1482 (6) Router B later retransmits the UPDATE packet to Router A. 1484 (7) Router A detects the duplicate and simply acknowledges the packet. 1485 Router B dequeues packet 11 from A's transmission list and both 1486 routers are up and synchronized. 1488 5.3.5 Neighbor Formation 1489 To prevent packets from being sent to a neighbor prior to verifying 1490 multicast and unicast packet delivery is reliable, a 3-way handshake 1491 is utilized. 1493 During normal adjacency formation, multicast HELLOs cause the EIGRP 1494 process to place new neighbors into the neighbor table. Unicast 1495 packets are then used to exchange known routing information, and 1496 complete the neighbor relationship (section 5.2) 1498 To prevent EIGRP from sending sequenced packets to neighbor which fail 1499 to have bidirectional unicast/multicast, or one neighbor restarts 1500 while building the relationship, EIGRP MUST place the newly discovered 1501 neighbor in a "pending" state as follows: 1503 When Router-A receives the first multicast HELLO from Router-B, it 1504 places Router-B in the pending state, and transmits a unicast UPDATE 1505 containing no topology information and SHALL set the initialization 1506 bit. While Router-B is in this state, A will not send it any a QUERY 1507 or UPDATE. When Router-A receives the unicast acknowledgement from 1508 Router-B, it will check the state from "pending" to "up". 1510 5.3.6 QUERY Packets During Neighbor Formation 1511 As described above, during the initial formation of the neighbor 1512 relationship, EIGRP uses a form of three-way handshake to verify both 1513 unicast and multicast connectivity are working successfully. During 1514 this period of neighbor creation, the new neighbor is considered to be 1515 the pending state, and is not eligible to be included in the 1516 convergence process. 1518 Because of this, any QUERY received by an EIGRP router would not cause 1519 a QUERY to be sent to the new (and pending) neighbor. It would perform 1520 the DUAL process without the new peer in the conversation. 1521 To do this, when a router in the process of establishing a new 1522 neighbor receives a QUERY from a fully established neighbor, it 1523 performs the normal DUAL Feasible Successor check to determine whether 1524 it needs to REPLY with a valid path or whether it needs to enter the 1525 ACTIVE process on the prefix. 1527 If it determines that it must go active, each fully established 1528 neighbor that participates in the convergence process will be sent a 1529 QUERY packet and REPLY packets are expected from each. Any pending 1530 neighbor will not be expected to REPLY and will not be sent a QUERY 1531 directly. If it resides on an interface containing a mix of fully 1532 established neighbors and pending neighbors, it might receive the 1533 QUERY but will not be expected to REPLY to it. 1535 5.4 Topology Table 1536 The Topology Table is populated by the protocol dependent modules 1537 (IPv4/IPv6 PDM), and is acted upon by the DUAL finite state machine. 1538 Associated with each entry are the destination address and a list of 1539 neighbors that have advertised this destination, and the metric 1540 associated with the destination. The metric is referred to as the 1541 Computed Distance. 1543 The Computed Distance is the best-advertised Reported Distance from 1544 all neighbors, plus the link cost between the receiving router and the 1545 neighbor. 1547 The Reported Distance is the Computed Distance as advertised by the 1548 Feasible Successor for the destination. Said another way, the Computed 1549 distance, when sent by a neighbor, is referred to as the Reported 1550 Distance and is the metric that the neighboring router uses to reach 1551 the destination (Its Computed Distance as described above). 1553 If the router is advertising a destination route, it MUST be using the 1554 route to forward packets; this is an important rule that distance 1555 vector protocols MUST follow. 1557 5.4.1 Route Management 1558 Within the topology table, EIGRP has the notion of internal and 1559 external routes. Internal routes MUST be preferred over external 1560 routes independent of the metric. In practical terms, if an internal 1561 route is received, the Diffusion computation will be run considering 1562 only the internal routes. Only when no internal routes for a given 1563 destination exist, will EIGRP choose the Successor from the available 1564 external routes. 1566 5.4.1.1 Internal Routes 1567 Internal routes are destinations that have been originated within the 1568 same EIGRP Autonomous System. Therefore, a directly attached network 1569 that is configured to run EIGRP is considered an internal route and is 1570 propagated with this information throughout the network topology. 1572 Internal routes are tagged with the following information: 1573 o Router ID of the EIGRP router that originated the route. 1574 o Configurable administrator tag. 1576 5.4.1.2 External routes 1577 External routes are destinations that have been learned from another 1578 source, such as a different routing protocol or static route. These 1579 routes are marked individually with the identity of their origination. 1580 External routes are tagged with the following information: 1581 o Router ID of the EIGRP router that redistributed the route. 1582 o AS number where the destination resides. 1583 o Configurable administrator tag. 1584 o Protocol ID of the external protocol. 1585 o Metric from the external protocol. 1586 o Bit flags for default routing. 1588 As an example, suppose there is an AS with three border routers (BR1, 1589 BR2, and BR3). A border router is one that runs more than one routing 1590 protocol. The AS uses EIGRP as the routing protocol. Two of the border 1591 routers, BR1 and BR2, also use Open Shortest Path First (OSPF) [10] 1592 and the other, BR3, also uses Routing Information Protocol (RIP). 1594 Routes learned by one of the OSPF border routers, BR1, can be 1595 conditionally redistributed into EIGRP. This means that EIGRP running 1596 in BR1 advertises the OSPF routes within its own AS. When it does so, 1597 it advertises the route and tags it as an OSPF learned route with a 1598 metric equal to the routing table metric of the OSPF route. The 1599 router-id is set to BR1. The EIGRP route propagates to the other 1600 border routers. 1602 Let's say that BR3, the RIP border router, also advertises the same 1603 destinations as BR1. Therefore, BR3, redistributes the RIP routes into 1604 the EIGRP AS. BR2, then, has enough information to determine the AS 1605 entry point for the route, the original routing protocol used, and the 1606 metric. 1608 Further, the network administrator could assign tag values to specific 1609 destinations when redistributing the route. BR2 can use any of this 1610 information to use the route or re-advertise it back out into OSPF. 1612 Using EIGRP route tagging can give a network administrator flexible 1613 policy controls and help customize routing. Route tagging is 1614 particularly useful in transit AS's where EIGRP would typically 1615 interact with an inter-domain routing protocol that implements global 1616 policies. 1618 5.4.2 Split Horizon and Poison Reverse 1619 In some circumstances, EIGRP will suppress or poison QUERY and UPDATE 1620 information to prevent routing loops as changes propagate though the 1621 network. 1623 The split horizon rule states: "Never advertise a route out of the 1624 interface through which it was learned". EIGRP implements this to 1625 mean if you have a Successor route to a destination, never advertise 1626 the route out the interface on which it was learned. 1628 The poison reverse rule states: "A route learned through an interface 1629 will be advertised as unreachable through that same interface". As 1630 with the case of Split Horizon, EIGRP applies this rule only to 1631 interfaces its is using for reaching the destination. Routes learned 1632 though interfaces which EIGRP is NOT using to reach the destination 1633 may have the route advertised out those interfaces. 1635 In EIGRP, split horizon suppresses a QUERY, where as Reverse Poison 1636 advertises a destination as unreachable. This can occur for a 1637 destination under any of the following conditions: 1639 o two routers are in startup or restart mode 1640 o advertising a topology table change 1641 o sending a query 1643 5.4.2.1 Startup Mode 1644 When two routers first become neighbors, they exchange topology tables 1645 during startup mode. For each destination a router receives during 1646 startup mode, it advertises the same destination back to its new 1647 neighbor with a maximum metric (Poison Route). 1649 5.4.2.2 Advertising Topology Table Change 1650 If a router uses a neighbor as the Successor for a given destination, 1651 it will send an UPDATE for the destination with a metric of infinity. 1653 5.4.2.3 Sending a QUERY/UPDATE 1654 In most cases EIGRP follows normal split-horizon rules. When a metric 1655 change is received from the Successor via QUERY or UPDATE that causes 1656 the route to go ACTIVE, the router will send a QUERY to neighbors on 1657 all interfaces except the interface toward the Successor. 1659 In other words, the router does not send the QUERY out of the inbound 1660 interface through which the information causing the route to go ACTIVE 1661 was received. 1663 An exception to this can occur if a router receives a QUERY from its 1664 successor while already reacting to an event that did not cause it to 1665 go ACTIVE. For example, a metric change from the Successor that did 1666 not cause an ACTIVE transition, but was followed by the UPDATE/QUERY 1667 that does result the router to transition to ACTIVE. 1669 5.5 EIGRP Metric Coefficients 1670 EIGRP allows for modification of the default composite metric 1671 calculation (See Section 5.6) through the use of coefficients (K- 1672 values). This adjustment allows for per-deployment tuning of network 1673 behavior. Setting K-values up to 254 scales the impact of the scalar 1674 metric on the final composite metric. 1676 EIGRP default coefficients have been carefully selected to provide 1677 optimal performance in most networks. The default K-values are 1679 K1 == K3 == 1 1680 K2 == K4 == K5 == 0 1681 K6 == 0 1683 If K5 is equal to 0 then reliability quotient is defined to be 1. 1685 5.5.1 Coefficients K1 and K2 1686 K1 is used to allow path selection to be based on the bandwidth 1687 available along the path. EIGRP can use one of two variations of 1688 Throughput based path selection. 1689 o Maximum Theoretical Bandwidth: paths chosen based on the highest 1690 reported bandwidth 1691 o Network Throughput: paths chosen based on the highest "available" 1692 bandwidth adjusted by congestion-based effects (interface reported 1693 load) 1695 By default, EIGRP computes the Throughput using the maximum 1696 theoretical throughput expressed in picoseconds per kilobyte of data 1697 sent. This inversion results in a larger number (more time) ultimately 1698 generating a worse metric. 1700 If K2 is used, the effect of congestion as a measure of load reported 1701 by the interface will be used to simulate the "available throughput" 1702 by adjusting the maximum throughput. 1704 5.5.2 Coefficient K3 1705 K3 is used to allow delay or latency-based path selection. Latency and 1706 Delay are similar terms that refer to the amount of time it takes a 1707 bit to be transmitted to an adjacent neighbor. EIGRP uses one-way 1708 based values either provided by the interface, or computed as a factor 1709 of the link s bandwidth. 1711 5.5.3 Coefficients K4 and K5 1712 K4 and K5 are used to allow for path selection based on link quality 1713 and packet loss. Packet loss caused by network problems result in 1714 highly noticeable performance issues or jitter with streaming 1715 technologies, voice over IP, online gaming and videoconferencing, and 1716 will affect all other network applications to one degree or another. 1718 Critical services should pass with less than 1% packet loss. Lower 1719 priority packet types might pass with less than 5% and then 10% for 1720 the lowest of priority of services. The final metric can be weighted 1721 based on the reported link quality. 1723 The handling of K5 is conditional. If K5 is equal to 0 then 1724 reliability quotient is defined to be 1. 1726 5.5.4 Coefficient K6 1727 K6 has been introduced with Wide Metric support and is used to allow 1728 for Extended Attributes, which can be used to reflect in a higher 1729 aggregate metric than those having lower energy usage. 1730 Currently there are two Extended Attributes, jitter and energy, 1731 defined in the scope of this document. 1733 5.5.4.1 Jitter 1734 Use of Jitter-based Path Selection results in a path calculation with 1735 the lowest reported jitter. Jitter is reported as the interval between 1736 the longest and shortest packet delivery and is expressed in 1737 microseconds. Higher values result in a higher aggregate metric when 1738 compared to those having lower jitter calculations. 1740 Jitter is measured in microseconds and is accumulated along the path, 1741 with each hop using an averaged 3-second period to smooth out the 1742 metric change rate. 1744 Presently, EIGRP does not currently have the ability to measure 1745 jitter, and as such the default value will be zero (0). Performance 1746 based solutions such as PfR could be used to populate this field. 1748 5.5.4.2 Energy 1749 Use of Energy-based Path Selection results in paths with the lowest 1750 energy usage being selected in a loop free and deterministic manner. 1751 The amount of energy used is accumulative and has results in a higher 1752 aggregate metric than those having lower energy. 1754 Presently, EIGRP does not report energy usage, and as such the default 1755 value will be zero (0). 1757 5.6 EIGRP Metric Calculations 1758 5.6.1 Classic Metrics 1759 The composite metric is based on bandwidth, delay, load, and 1760 reliability. MTU is not an attribute for calculating the composite 1761 metric, but carried in the vector metrics. 1763 One of the original goals of EIGRP was to offer and enhance routing 1764 solutions for IGRP. To achieve this, EIGRP used the same composite 1765 metric as IGRP, with the terms multiplied by 256 to change the metric 1766 from 24 bits to 32 bits. 1768 5.6.1.1 Classic Composite Formulation 1769 EIGRP calculates the composite metric with the following formula: 1771 metric = 256*({(K1*BW)+[(K2*BW)/(256-LOAD)]+(K3*DELAY)}*(K5/(REL+K4))) 1773 In this formula, Bandwidth (BW) is the lowest interface bandwidth 1774 along the path, and delay (DELAY) is the sum of all outbound interface 1775 delays along the path. Load (LOAD) and reliability (REL) values are 1776 expressed percentages with a value of 1 to 255. 1778 Implementation note: Cisco IOS routers display reliability as a 1779 fraction of 255. That is, 255/255 is 100 percent reliability or a 1780 perfectly stable link; a value of 229/255 represents a 90 percent 1781 reliable link. Load is a value between 1 and 255. A load of 255/255 1782 indicates a completely saturated link. A load of 127/255 represents a 1783 50 percent saturated link. These values are not dynamically measured 1784 they are only measured at the time a link changes. 1786 Bandwidth is the inverse minimum bandwidth (in kbps) of the path in 1787 bits per second scaled by a factor of 10^7. The formula for bandwidth 1788 is 1789 (10^7)/BWmin 1791 Implementation note: When converting the real bandwidth to the 1792 composite bandwidth, truncate before applying the scaling factor. 1793 When converting the composite bandwidth to the real bandwidth, apply 1794 the scaling factor before the division and only then truncate. 1796 The delay is the sum of the outgoing interface delay (in tens of 1797 microseconds) to the destination. A delay set to it maximum value 1798 (hexadecimal 0xFFFFFFFF) indicates that the network is unreachable. 1799 The formula for delay is 1801 [sum of delays] 1803 The default composite metric, adjusted for scaling factors, for EIGRP 1804 is: 1806 metric = 256 x { [(10^7)/ BWmin] + [sum of delays]} 1808 Minimum Bandwidth (BWmin) is represented in kbps, and the "sum of 1809 delays" is represented in 10s of microseconds. The bandwidth and delay 1810 for an Ethernet interface are 10Mbps and 1ms, respectively. 1812 The calculated EIGRP bandwidth (BW) metric is then: 1814 256 x (10^7)/BW = 256 x {(10^7)/10,000} 1815 = 256 x 1000 1816 = 256,000 1818 And the calculated EIGRP delay metric is then: 1820 256 x sum of delay = 256 x 100 x 10 microseconds 1821 = 25,600 (in tens of microseconds) 1823 5.5.1.2 Cisco Interface Delay Compatibility 1824 For compatibility with Cisco products, the following table shows the 1825 times in nanoseconds EIGRP uses for bandwidth and delay 1826 Bandwidth Classic Wide Metrics Interface 1827 (Kbps) Delay Delay Type 1828 --------------------------------------------------------- 1829 9 500000000 500000000 Tunnel 1830 56 20000000 20000000 56Kb/s 1831 64 20000000 20000000 DS0 1832 1544 20000000 20000000 T1 1833 2048 20000000 20000000 E1 1834 10000 1000000 1000000 Ethernet 1835 16000 630000 630000 TokRing16 1836 45045 20000000 20000000 HSSI 1837 100000 100000 100000 FDDI 1838 100000 100000 100000 FastEthernet 1839 155000 100000 100000 ATM 155Mb/s 1840 1000000 10000 10000 GigaEthernet 1841 2000000 10000 5000 2 Gig 1842 5000000 10000 2000 5 Gig 1843 10000000 10000 1000 10 Gig 1844 20000000 10000 500 20 Gig 1845 50000000 10000 200 50 Gig 1846 100000000 10000 100 100 Gig 1847 200000000 10000 50 200 Gig 1848 500000000 10000 20 500 Gig 1850 5.6.2 Wide Metrics 1851 To accommodate interfaces with high bandwidths, and to allow EIGRP to 1852 perform the path selection; the EIGRP packet and composite metric 1853 formula has been modified to choose paths based on the computed time, 1854 measured in picoseconds, information takes to travel though the links. 1856 5.6.2.1 Wide Metric Vectors 1857 EIGRP uses five "vector metrics": minimum throughput, latency, load, 1858 reliability, and maximum transmission unit (MTU). These values are 1859 calculated from destination to source as follows: 1860 o Throughput - Minimum value 1861 o Latency - accumulative 1862 o Load - maximum 1863 o Reliability - minimum 1864 o MTU - minimum 1865 o Hop count - accumulative 1867 To this there are two additional values: jitter and energy. These two 1868 values are accumulated from destination to source: 1869 o Jitter - accumulative 1870 o Energy - accumulative 1872 These Extended Attributes, as well as any future ones, will be 1873 controlled via K6. If K6 is non-zero, these will be additive to the 1874 path's composite metric. Higher jitter or energy usage will result in 1875 paths that are worse than those which either does not monitor these 1876 attributes, or which have lower values. 1878 EIGRP will not send these attributes if the router does not provide 1879 them. If the attributes are received, then EIGRP will use them in the 1880 metric calculation (based on K6) and will forward them with those 1881 routers values assumed to be "zero" and the accumulative values are 1882 forwarded unchanged. 1884 The use of the vector metrics allows EIGRP to compute paths based on 1885 any of four (bandwidth, delay, reliability, and load) path selection 1886 schemes. The schemes are distinguished based on the choice of the key 1887 measured network performance metric. 1889 Of these vector metric components, by default, only minimum throughput 1890 and latency are traditionally used to compute best path. Unlike most 1891 metrics, minimum throughput is set to the minimum value of the entire 1892 path, and it does not reflect how many hops or low throughput links 1893 are in the path, nor does it reflect the availability of parallel 1894 links. Latency is calculated based on one-way delays, and is a 1895 cumulative value, which increases with each segment in the path. 1897 Network Designers Note: when trying to manually influence EIGRP path 1898 selection though interface bandwidth/delay configuration, the 1899 modification of bandwidth is discouraged for following reasons: 1901 The change will only effect the path selection if the configured value 1902 is the lowest bandwidth over the entire path. 1903 Changing the bandwidth can have impact beyond affecting the EIGRP 1904 metrics. For example, Quality of Service (QoS) also looks at the 1905 bandwidth on an interface. 1907 EIGRP throttles its packet transmissions so it will only use 50 1908 percent of the configured bandwidth. Lowering the bandwidth can cause 1909 EIGRP to starve an adjacency, causing slow or failed convergence and 1910 control plane operation. 1912 Changing the delay does not impact other protocols nor does it cause 1913 EIGRP to throttle back; changing the delay configured on a link only 1914 impacts metric calculation. 1916 5.6.2.2 Wide Metric Conversion Constants 1917 EIGRP uses a number of defined constants for conversion and 1918 calculation of metric values. These numbers are provided here for 1919 reference 1921 EIGRP_BANDWIDTH 10,000,000 1922 EIGRP_DELAY_PICO 1,000,000 1923 EIGRP_INACCESSIBLE 0xFFFFFFFFFFFFFFFFLL 1924 EIGRP_MAX_HOPS 100 1925 EIGRP_CLASSIC_SCALE 256 1926 EIGRP_WIDE_SCALE 65536 1928 When computing the metric using the above units, all capacity 1929 information will be normalized to kilobytes and picoseconds before 1930 being used. For example, delay is expressed in microseconds per 1931 kilobyte, and would be converted to kilobytes per second; likewise, 1932 energy would be expressed in power per kilobytes per second of usage. 1934 5.6.2.3 Throughput Calculation 1935 The formula for the conversion for Max-Throughput value directly from 1936 the interface without consideration of congestion-based effects is as 1937 follows: 1939 (EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE) 1940 Max-Throughput = K1 * ------------------------------------ 1941 Interface Bandwidth (kbps) 1943 If K2 is used, the effect of congestion as a measure of load reported 1944 by the interface will be used to simulate the "available throughput" 1945 by adjusting the maximum throughput according to the formula: 1947 K2 * Max-Throughput 1948 Net-Throughput = Max-Throughput + --------------------- 1949 256 - Load 1950 K2 has the greatest effect on the metric occurs when the load 1951 increases beyond 90%. 1953 5.6.2.4 Latency Calculation 1954 Transmission times derived from physical interfaces MUST be n units of 1955 picoseconds, or converted to picoseconds prior to being exchanged 1956 between neighbors, or used in the composite metric determination. 1958 This includes delay values present in configuration-based commands 1959 (i.e. interface delay, redistribute, default-metric, route-map, etc.) 1961 The delay value is then converted to a "latency" using the formula: 1963 Delay * EIGRP_WIDE_SCALE 1964 Latency = K3 * -------------------------- 1965 EIGRP_DELAY_PICO 1967 5.6.2.5 Composite Calculation 1968 K5 1969 metric =[(K1*Net-Throughput) + Latency)+(K6*ExtAttr)] * ------ 1970 K4+Rel 1972 By default, the path selection scheme used by EIGRP is a combination 1973 of Throughput and Latency where the selection is a product of total 1974 latency and minimum throughput of all links along the path: 1976 metric = (K1 * min(Throughput)) + (K3 * sum(Latency)) } 1978 6 EIGRP Packet Formats 1980 6.1 Protocol Number 1981 The IPv6 and IPv4 protocol identifier number spaces are common and 1982 will both use protocol identifier 88 [8] [9]. 1984 EIGRP IPv4 will transmit HELLO packets using either the unicast 1985 destination of a neighbor or using a multicast host group address [7] 1986 with a source address EIGRP IPv4 multicast address [13]. 1988 EIGRP IPv6 will transmit HELLO packets with a source address being the 1989 link-local address of the transmitting interface. Multicast HELLO 1990 packets will have a destination address of EIGRP IPv6 multicast 1991 address [14]. Unicast packets directed to a specific neighbor 1992 will contain the destination link-local address of the neighbor. 1994 There is no requirement that two EIGRP IPv6 neighbors share a common 1995 prefix on their connecting interface. EIGRP IPv6 will check that a 1996 received HELLO contains a valid IPv6 link-local source address. Other 1997 HELLO processing will follow common EIGRP checks, including matching 1998 Autonomous system number and matching K-values. 2000 6.2 Protocol Assignment Encoding 2001 External Protocol Field is an informational assignment to identify the 2002 originating routing protocol that this route was learned by. The 2003 following values are assigned: 2005 Protocols Value 2006 IGRP 1 2007 EIGRP 2 2008 Static 3 2009 RIP 4 2010 HELLO 5 2011 OSPF 6 2012 ISIS 7 2013 EGP 8 2014 BGP 9 2015 IDRP 10 2016 Connected 11 2018 6.3 Destination Assignment Encoding 2019 Destinations types are encoded according to the IANA address family 2020 number assignments. Currently only the following types are used: 2022 AFI Designation AFI Value 2023 -------------------------------------- 2024 IPv4 Address 1 2025 IPv6 Address 2 2026 Service Family Common 16384 2027 Service Family IPv4 16385 2028 Service Family IPv6 16386 2030 6.4 EIGRP Communities Attribute 2031 EIGRP supports communities similar to the BGP Extended Communities RFC 2032 4360 [4] extended type with Type Field composed of 2 octets and Value 2033 Field composed of 6 octets. Each Community is encoded as an 8-octet 2034 quantity, as follows: 2035 - Type Field: 2 octets 2036 - Value Field: Remaining octets 2038 0 1 2 3 2039 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 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 | Type high | Type low | | 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | 2043 | | 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 In addition to well-known communities supported by BGP (such as Site 2047 of Origin), EIGRP defines a number of additional Community values in 2048 the "Experimental Use" [5] range as follows: 2050 Type high: 0x88 2051 Type low: 2053 Value Name Description 2054 --------------------------------------------------------------- 2055 00 EXTCOMM_EIGRP EIGRP route information appended 2056 01 EXTCOMM_DAD Data: AS + Delay 2057 02 EXTCOMM_VRHB Vector: Reliability + Hop + BW 2058 03 EXTCOMM_SRLM System: Reserve + Load + MTU 2059 04 EXTCOMM_SAR System: Remote AS + Remote ID 2060 05 EXTCOMM_RPM Remote: Protocol + Metric 2061 06 EXTCOMM_VRR Vecmet: Rsvd + RouterID 2063 6.5 EIGRP Packet Header 2064 The basic EIGRP packet payload format is identical for both IPv4 and 2065 IPv6, although there are some protocol-specific variations. Packets 2066 consist of a header, followed by a set of variable-length fields 2067 consisting of Type/Length/Value (TLV) triplets. 2069 0 1 2 3 2070 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 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 |Header Version | Opcode | Checksum | 2073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2074 | Flags | 2075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2076 | Sequence Number | 2077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2078 | Acknowledgement number | 2079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2080 | Virtual Router ID | Autonomous system number | 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 Header Version - EIGRP Packet Header Format version. Current Version 2084 is 2. This field is not the same as the TLV Version field. 2086 Opcode - Indicates the type of the message. It will be one of the 2087 following values: 2089 EIGRP_OPC_UPDATE 1 2090 EIGRP_OPC_REQUEST 2 2091 EIGRP_OPC_QUERY 3 2092 EIGRP_OPC_REPLY 4 2093 EIGRP_OPC_HELLO 5 2094 Reserved 6 (EIGRP_OPC_IPXSAP) 2095 Reserved 7 (EIGRP_OPC_PROBE) 2096 Reserved 8 (EIGRP_OPC_ACK) 2097 Reserved 9 2098 EIGRP_OPC_SIAQUERY 10 2099 EIGRP_OPC_SIAREPLY 11 2101 Checksum - Each packet will include a checksum for the entire contents 2102 of the packet. The check-sum will be the standard ones complement of 2103 the ones complement sum. For purposes of computing the checksum, the 2104 value of the checksum field is zero. The packet is discarded if the 2105 packet checksum fails. 2107 Flags - Defines special handling of the packet. There are currently 2108 four defined flag bits. 2110 Init Flag (0x01) - This bit is set in the initial UPDATE sent to a 2111 newly discovered neighbor. It instructs the neighbor to advertise its 2112 full set of routes. 2114 CR Flag (0x02) - This bit indicates that receivers should only accept 2115 the packet if they are in Conditionally Received mode. A router enters 2116 conditionally received mode when it receives and processes a HELLO 2117 packet with a Sequence TLV present. 2119 RS (0x04) - The Restart flag is set in the HELLO and the UPDATE 2120 packets during the restart period. The router looks at the RS flag to 2121 detect if a neighbor is restarting. From the restarting routers 2122 perspective, if a neighboring router detects the RS flag set, it will 2123 maintain the adjacency, and will set the RS flag in its UPDATE packet 2124 to indicated it is doing a soft restart. 2126 EOT (0x08) - The End-of-Table flag marks the end of the startup 2127 process with a neighbor. If the flag is set, it indicates the neighbor 2128 has completed sending all UPDATEs. At this point the router will 2129 remove any stale routes learned from the neighbor prior to the restart 2130 event. A stale route is any route, which existed before the restart, 2131 and was not refreshed by the neighbor via and UPDATE. 2133 Sequence - Each packet that is transmitted will have a 32-bit sequence 2134 number that is unique with respect to a sending router. A value of 0 2135 means that an acknowledgment is not required. 2137 ACK - The 32-bit sequence number that is being acknowledged with 2138 respect to the receiver of the packet. If the value is 0, there is no 2139 acknowledgment present. A non-zero value can only be present in 2140 unicast-addressed packets. A HELLO packet with a nonzero ACK field 2141 should be decoded as an ACK packet rather than a HELLO packet. 2143 Virtual Router ID (VRID) - A 16-bit number which identifies the 2144 virtual router this packet is associated with. Packets received with 2145 an unknown, or unsupported, value will be discarded. 2147 Value Range Usage 2148 0x0000 Unicast Address Family 2149 0x0001 Multicast Address Family 2150 0x0002-0x7FFF Reserved 2151 0x8000 Unicast Service Family 2152 0x8001-0xFFFF Reserved 2154 Autonomous System (AS) - 16-bit unsigned number of the sending system. 2155 This field is indirectly used as an authentication value. That is, a 2156 router that receives and accepts a packet from a neighbor must have 2157 the same AS number or the packet is ignored. The range of valid AS 2158 numbers is 1 through 65,535. 2160 6.6 EIGRP TLV Encoding Format 2161 The contents of each packet can contain a variable number of fields. 2162 Each field will be tagged and include a length field. This allows for 2163 newer versions of software to add capabilities and coexist with old 2164 versions of software in the same configuration. Fields that are tagged 2165 and not recognized can be skipped over. Another advantage of this 2166 encoding scheme allows multiple network layer protocols to carry 2167 independent information. Therefore, later if it is decided to 2168 implement a single "integrated" protocol this can be done. 2170 The format of a {type, length, value} (TLV) is encoded as follows: 2172 0 1 2 3 2173 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 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2175 | Type high | Type low | Length | 2176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2177 | Value (variable length) | 2178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2180 The type values are the ones defined below. The length value specifies 2181 the length in octets of the type, length and value fields. TLVs can 2182 appear in a packet in any order and there are no inter-dependencies 2183 among them. 2185 Malformed TLVs contained in EIGRP messages are handled by silently 2186 discarding the containing message. A TLV is malformed if the TLV 2187 Length is invalid or if the TLV extends beyond the end of the 2188 containing message. 2190 6.6.1 Type Field Encoding 2191 The type field is structured as follows: 2192 Type High: 1 octet that defines the protocol classification: 2193 Protocol ID VERSION 2194 General 0x00 1.2 2195 IPv4 0x01 1.2 2196 IPv6 0x04 1.2 2197 SAF 0x05 3.0 2198 Multi-Protocol 0x06 2.0 2200 Type Low: 1 octet that defines the TLV Opcode; See TLV Definitions in 2201 Section 3. 2203 6.6.2 Length Field Encoding 2204 The Length field is a 2 octet unsigned number, which indicates the 2205 length of the TLV. The value includes the Type and Length fields 2206 6.6.3 Value Field Encoding 2207 The Value field is a multi-octet field containing the payload for the 2208 TLV. 2210 6.7 EIGRP Generic TLV Definitions 2211 Ver 1.2 Ver 2.0 2212 PARAMETER_TYPE 0x0001 0x0001 2213 AUTHENTICATION_TYPE 0x0002 0x0002 2214 SEQUENCE_TYPE 0x0003 0x0003 2215 SOFTWARE_VERSION_TYPE 0x0004 0x0004 2216 MULTICAST_SEQUENCE_TYPE 0x0005 0x0005 2217 PEER_INFORMATION_TYPE 0x0006 0x0006 2218 PEER_TERMINATION_TYPE 0x0007 0x0007 2219 PEER_TID_LIST_TYPE --- 0x0008 2221 6.7.1 0x0001 - PARAMETER_TYPE 2222 This TLV is used in HELLO packets to convey the EIGRP metric 2223 coefficient values - noted as "K-values" as well as the Hold Time 2224 values. This TLV is also used in an initial UPDATE packet when a 2225 neighbor is discovered. 2227 0 1 2 3 2228 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 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 | 0x0001 | 0x000C | 2231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 | K1 | K2 | K3 | K4 | 2233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2234 | K5 | K6 | Hold Time | 2235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2237 K-values - The K-values associated with the EIGRP composite metric 2238 equation. The default values for weights are: 2239 K1 - 1 2240 K2 - 0 2241 K3 - 1 2242 K4 - 0 2243 K5 - 0 2244 K6 - 0 2246 Hold Time - The amount of time in seconds that a receiving router 2247 should consider the sending neighbor valid. A valid neighbor is one 2248 that is able to forward packets and participates in EIGRP. A router 2249 that considers a neighbor valid will store all routing information 2250 advertised by the neighbor. 2252 6.7.2 0x0002 - AUTHENTICATION_TYPE 2253 This TLV may be used in any EIGRP packet and conveys the 2254 authentication type and data used. Routers receiving a mismatch in 2255 authentication shall discard the packet. 2257 0 1 2 3 2258 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 2259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2260 | 0x0002 | Length | 2261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2262 | Auth Type | Auth Length | Auth Data (Variable) | 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2265 Authentication Type - The type of authentication used. 2266 Authentication Length - The length, measured in octets, of the 2267 individual authentication. 2269 Authentication Data - Variable length field reflected by "Auth Length" 2270 which is dependent on the type of authentication used. Multiple 2271 authentication types can be present in a single AUTHENTICATION_TYPE 2272 TLV. 2274 6.7.2.1 0x02 - MD5 Authentication Type 2275 MD5 Authentication will use Auth Type code 0x02, and the Auth Data 2276 will be the MD5 Hash value. 2278 6.7.2.2 0x03 - SHA2 Authentication Type 2279 SHA2-256 Authentication will use Type code 0x03, and the Auth Data 2280 will be the 256 bit SHA2 [6] Hash value 2282 6.7.3 0x0003 - SEQUENCE_TYPE 2283 This TLV is used for a sender to tell receivers to not accept packets 2284 with the CR-flag set. This is used to order multicast and unicast 2285 addressed packets. 2287 0 1 2 3 2288 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 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2290 | 0x0003 | Length | 2291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2292 |Address Length | Protocol Address | 2293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2295 The Address Length and Protocol Address will be repeated one or more 2296 times based on the Length Field. 2298 Address Length - Number of octets for the address that follows. For 2299 IPv4, the value is 4. For IPv6 it is 16. While no longer in use, for 2300 AppleTalk, the value is 4 and for Novell IPX, the value is 10, 2302 Protocol Address - Neighbor address on interface in which the HELLO 2303 with SEQUENCE TLV is sent. Each address listed in the HELLO packet is 2304 a neighbor that should not enter Conditionally Received mode. 2306 6.7.4 0x0004 - SOFTWARE_VERSION_TYPE 2307 Field Length 2308 Vender OS major version 1 2309 Vender OS minor version 1 2310 EIGRP major revision 1 2311 EIGRP minor revision 1 2313 The EIGRP TLV Version fields are used to determine TLV format 2314 versions. Routers using Version 1.2 TLVs do not understand version 2.0 2315 TLVs, therefore Version 2.0 routers must send the packet with both TLV 2316 formats in a mixed network. 2318 0 1 2 3 2319 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 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 | 0x0004 | 0x000C | 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 |Vendor Major V.|Vendor Minor V.| EIGRP Major V.| EIGRP Minor V.| 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 6.7.5 0x0005 - MULTICAST_SEQUENCE_TYPE 2327 The next multicast sequence TLV. 2329 0 1 2 3 2330 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 2331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2332 | 0x0005 | 0x0008 | 2333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2334 | Sequence Number | 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2337 6.7.6 0x0006 - PEER_INFORMATION_TYPE 2338 This TLV is reserved, and not part of this IETF document. 2340 6.7.7 0x0007 - PEER_ TERMINATION_TYPE 2341 This TLV is used in HELLO Packets to notify the list of neighbor(s) 2342 the router has reset the adjacency. This is used anytime a router 2343 need to expedite a doing down process so the neighbors can process 2344 the down neighbor without waiting for a HELLO timeout. 2346 0 1 2 3 2347 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 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 | 0x0007 | Length | 2350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 | Address List (variable) | 2352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 Implementation note: Older Cisco routers implement this using the 2355 "Parameters TLV" with all K-values set to 255 (except K6). 2357 6.7.8 0x0008 - TID_LIST_TYPE 2358 List of sub-topology identifiers, including the base topology, 2359 supported by the router. 2361 0 1 2 3 2362 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 2363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2364 | 0x0008 | Length | 2365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2366 | Topology Identification List (variable) | 2367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2369 If this information changes from the last state, it means either a new 2370 topology was added, or an existing topology was removed. This TLV is 2371 ignored until the three-way handshake has finished 2373 When the TID list is received, it compares the list to the previous 2374 list sent. If a TID is found which does not previously exist, the TID 2375 is added to the neighbor's topology list, and the existing sub- 2376 topology is sent to the peer. 2378 If a TID, which was in a previous list, is not found, the TID is 2379 removed from the neighbor's topology list and all routes learned 2380 though that neighbor for that sub-topology are removed from the 2381 topology table. 2383 6.8 Classic Route Information TLV Types 2384 6.8.1 Classic Flag Field Encoding 2385 EIGRP transports a number of flags with in the TLVs to indicate 2386 addition route state information. These bits are defined as follows: 2388 Flags Field 2389 ----------- 2390 Source Withdraw (Bit 0) - Indicates if the router which is the 2391 original source of the destination is withdrawing the route from the 2392 network, or if the destination is lost due as a result of a network 2393 failure. 2395 Candidate Default (CD) (Bit 1) - Set to indicate the destination 2396 should be regarded as a candidate for the default route. An EIGRP 2397 default route is selected from all the advertised candidate default 2398 routes with the smallest metric. 2400 ACTIVE (Bit 2) - Indicates if the route is in the ACTIVE State. 2401 6.8.2 Classic Metric Encoding 2402 The handling of bandwidth and delay for Classic TLVs are encoded in 2403 the packet "scaled" form relative to how they are represented on the 2404 physical link. 2406 0 1 2 3 2407 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 2408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2409 | Scaled Delay | 2410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2411 | Scaled Bandwidth | 2412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2413 | MTU | Hop-Count | 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2415 | Reliability | Load | Internal Tag | Flags Field | 2416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2418 Scaled Delay - An administrative parameter assigned statically on a 2419 per interface type basis to represent the time it takes along an 2420 unloaded path. This is expressed in units of 10s of microseconds 2421 divvied by 256. A delay of 0xFFFFFFFF indicates an unreachable route. 2423 Scaled Bandwidth - The path bandwidth measured in bits per second. In 2424 units of 2,560,000,000/kbps 2426 MTU - The minimum maximum transmission unit size for the path to the 2427 destination. 2429 Hop Count - The number of router traversals to the destination. 2431 Reliability - The current error rate for the path. Measured as an 2432 error percentage. A value of 255 indicates 100% reliability 2434 Load - The load utilization of the path to the destination, measured 2435 as a percentage. A value of 255 indicates 100% load. 2437 Internal-Tag - A tag assigned by the network administrator that is 2438 untouched by EIGRP. This allows a network administrator to filter 2439 routes in other EIGRP border routers based on this value. 2441 Flag Field - See Section 6.8.1 2443 6.8.3 Classic Exterior Encoding 2444 Additional routing information so provided for destinations outside of 2445 the EIGRP autonomous system as follows: 2447 0 1 2 3 2448 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 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2450 | Router Identification (RID) | 2451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2452 | External Autonomous System Number (AS) | 2453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2454 | Administrative Tag | 2455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 | External Protocol Metric | 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 | Reserved |Extern Protocol| Flags Field | 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 Router Identifier (RID) - A 32-bit number provided by the router 2462 sourcing the information to uniquely identify it as the source. 2464 External Autonomous System (AS) - 32-bit number indicating the 2465 external autonomous system the sending router is a member of. If the 2466 source protocol is EIGRP, this field will be the [VRID|AS] pair. If 2467 the external protocol does not have an AS, other information can be 2468 used (example Cisco uses process-id for OSPF). 2470 Administrator Tag - A tag assigned by the network administrator that 2471 is untouched by EIGRP. This allows a network administrator to filter 2472 routes in other EIGRP border routers based on this value. 2474 External Protocol Metric 32-bit value of the composite metric that 2475 resides in the routing table as learned by the foreign protocol. If 2476 the External Protocol is IGRP or another EIGRP routing process, the 2477 value can optionally be the composite metric or 0, and the metric 2478 information is stored in the metric section. 2480 External Protocol - Defines the external protocol that this route was 2481 learned. See Section 6.2 2483 Flag Field - See Section 6.8.1 2485 6.8.4 Classic Destination Encoding 2486 EIGRP carries destination in a compressed form, where the number of 2487 bits significant in the variable length address field are indicated in 2488 a counter: 2490 0 1 2 3 2491 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 2492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2493 | Subnet Mask | Destination Address (variable length) | 2494 | Bit Count | ((Bit Count - 1) / 8) + 1 | 2495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2497 Subnet Mask Bit Count - 8-bit value used to indicate the number of 2498 bits in the subnet mask. A value of 0 indicates the default network 2499 and no address is present. 2501 Destination Address - A variable length field used to carry the 2502 destination address. The length is determined by the number of 2503 consecutive bits in the destination address. The formula to calculate 2504 the length is address-family dependent: 2506 IPV4: ((Bit Count - 1) / 8) + 1 2507 IPv6: (Bit Count == 128) ? 16 : ((x / 8) + 1) 2509 6.8.5 IPv4 Specific TLVs 2511 INTERNAL_TYPE 0x0102 2512 EXTERNAL_TYPE 0x0103 2513 COMMUNITY_TYPE 0x0104 2515 6.8.5.1 IPv4 INTERNAL_TYPE 2516 This TLV conveys IPv4 destination and associated metric information 2517 for IPv4 networks. Routes advertised in this TLV are network 2518 interfaces that EIGRP is configured on as well as networks that are 2519 learned via other routers running EIGRP. 2521 0 1 2 3 2522 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 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2524 | 0x01 | 0x02 | Length | 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 | Next Hop Forwarding Address | 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 | Vector Metric Section (See Section 6.8.2) | 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2530 | Destination Section | 2531 | IPv4 Address (variable length) | 2532 | (See Section 6.8.4) | 2533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 Next Hop Forwarding Address - IPv4 address is represented by 4 8-bit 2536 values (total 4 octets). If the value is zero (0), the IPv4 address 2537 from the received IPv4 header is used as the next-hop for the route. 2538 Otherwise, the specified IPv4 address will be used. 2540 Metric Section - vector metrics for destinations contained in this 2541 TLV. See description of metric encoding in section 6.8.2 2543 Destination Section - The network/subnet/host destination address 2544 being requested. See description of destination in section 6.8.4 2545 6.8.5.2 IPv4 EXTERNAL_TYPE 2546 This TLV conveys IPv4 destination and metric information for routes 2547 learned by other routing protocols that EIGRP injects into the AS. 2548 Available with this information is the identity of the routing 2549 protocol that created the route, the external metric, the AS number, 2550 an indicator if it should be marked as part of the EIGRP AS, and a 2551 network administrator tag used for route filtering at EIGRP AS 2552 boundaries. 2554 0 1 2 3 2555 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 2556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 | 0x01 | 0x03 | Length | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2559 | Next Hop Forwarding Address | 2560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2561 | Exterior Section (See Section6.8.3) | 2562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2563 | Vector Metric Section (See Section 6.8.2) | 2564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2565 | Destination Section | 2566 | IPv4 Address (variable length) | 2567 | (See Section 6.8.4) | 2568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2570 Next Hop Forwarding Address - IPv4 address is represented by 4 8-bit 2571 values (total 4 octets). If the value is zero (0), the IPv4 address 2572 from the received IPv4 header is used as the next-hop for the route. 2573 Otherwise, the specified IPv4 address will be used 2575 Exterior Section - Additional routing information provides for a 2576 destination outside of the autonomous system and that has been 2577 redistributed into the EIGRP. See Section 6.8.3 2579 Metric Section - vector metrics for destinations contained in this 2580 TLV. See description of metric encoding in Section 6.8.2 2582 Destination Section - The network/subnet/host destination address 2583 being requested. See description of destination in Section 6.8.4 2584 6.8.5.3 IPv4 COMMUNITY_TYPE 2585 This TLV is used to provide community tags for specific IPv4 2586 destinations. 2588 0 1 2 3 2589 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 2590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2591 | 0x01 | 0x04 | Length | 2592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 | IPv4 Destination | 2594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2595 | Reserved | Community Length | 2596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2597 | Community List | 2598 | (variable length) | 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 Destination - The IPv4 address the community information should be 2602 stored with. 2604 Community Length - 2 octet unsigned number that indicates the length 2605 of the Community List. The length does not include the IPv4 Address, 2606 reserved, or Length fields 2608 Community List - One or more 8 octet EIGRP community as defined in 2609 section 6.4 2610 6.8.6 IPv6 Specific TLVs 2612 INTERNAL_TYPE 0x0402 2613 EXTERNAL_TYPE 0x0403 2614 COMMUNITY_TYPE 0x0404 2616 6.8.6.1 IPv6 INTERNAL_TYPE 2617 This TLV conveys IPv6 destination and associated metric information 2618 for IPv6 networks. Routes advertised in this TLV are network 2619 interfaces that EIGRP is configured on as well as networks that are 2620 learned via other routers running EIGRP. 2622 0 1 2 3 2623 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 2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2625 | 0x04 | 0x02 | Length | 2626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2627 | Next Hop Forwarding Address | 2628 | (16 octets) | 2629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2630 | Vector Metric Section (See Section 6.8.2) | 2631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2632 | Destination Section | 2633 | IPv6 Address (variable length) | 2634 | (See Section 6.8.4) | 2635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2637 Next Hop Forwarding Address - IPv6 address is represented by 8 groups 2638 of 16-bit values (total 16 octets). If the value is zero (0), the IPv6 2639 address from the received IPv6 header is used as the next-hop for the 2640 route. 2642 Metric Section - vector metrics for destinations contained in this 2643 TLV. See description of metric encoding in section 6.8.2 2645 Destination Section - The network/subnet/host destination address 2646 being requested. See description of destination in section 6.8.4 2647 6.8.6.2 IPv6 EXTERNAL_TYPE 2648 This TLV conveys IPv6 destination and metric information for routes 2649 learned by other routing protocols that EIGRP injects into the 2650 topology. Available with this information is the identity of the 2651 routing protocol that created the route, the external metric, the AS 2652 number, an indicator if it should be marked as part of the EIGRP AS, 2653 and a network administrator tag used for route filtering at EIGRP AS 2654 boundaries. 2656 0 1 2 3 2657 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 2658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2659 | 0x04 | 0x03 | Length | 2660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 | Next Hop Forwarding Address | 2662 | (16 octets) | 2663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2664 | Exterior Section (See Section6.8.3) | 2665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2666 | Vector Metric Section (See Section 6.8.2) | 2667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2668 | Destination Section | 2669 | IPv6 Address (variable length) | 2670 | (See Section 6.8.4) | 2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 Next Hop Forwarding Address - IPv6 address is represented by 8 groups 2674 of 16-bit values (total 16 octets). If the value is zero (0), the IPv6 2675 address from the received IPv6 header is used as the next-hop for the 2676 route. Otherwise, the specified IPv6 address will be used. 2678 Exterior Section - Additional routing information provided for a 2679 destination outside of the autonomous system and that has been 2680 redistributed into the EIGRP. See description of exterior encoding in 2681 Section 6.8.3 2683 Metric Section - vector metrics for destinations contained in this 2684 TLV. See description of metric encoding in section 6.8.2 2686 Destination Section - The network/subnet/host destination address 2687 being requested. See description of destination in section 6.8.4 2688 6.8.6.3 IPv6 COMMUNITY_TYPE 2689 This TLV is used to provide community tags for specific IPv4 2690 destinations. 2692 0 1 2 3 2693 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 2694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2695 | 0x04 | 0x04 | Length | 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 | Destination | 2698 | (16 octets) | 2699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2700 | Reserved | Community Length | 2701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 | Community List | 2703 | (variable length) | 2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2706 Destination - The IPv6 address the community information should be 2707 stored with. 2709 Community Length - 2 octet unsigned number that indicates the length 2710 of the Community List. The length does not include the IPv6 Address, 2711 Reserved or Length fields 2713 Community List - One or more 8 octet EIGRP community as defined in 2714 section 6.4 2715 6.9 Multi-Protocol Route Information TLV Types 2716 This TLV conveys topology and associated metric information 2718 0 1 2 3 2719 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 2720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2721 |Header Version | Opcode | Checksum | 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 | Flags | 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2725 | Sequence Number | 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2727 | Acknowledgement number | 2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2729 | Virtual Router ID | Autonomous system number | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2731 | TLV Header Encoding | 2732 | (See Section 6.9.1) | 2733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2734 | Wide Metric Encoding | 2735 | (See Section 6.9.2) | 2736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2737 | Destination Descriptor | 2738 | (variable length) | 2739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2741 6.9.1 TLV Header Encoding 2742 There has been a long-standing requirement for EIGRP to support 2743 routing technologies such as multi-topologies and provide the ability 2744 to carry destination information independent of the transport. To 2745 accomplish this, a Vector has been extended to have a new "Header 2746 Extension Header" section. This is a variable length field and, at a 2747 minimum, will support the following fields: 2749 0 1 2 3 2750 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 2751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2752 | Type high | Type low | Length | 2753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2754 | AFI | TID | 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 | Router Identifier (RID) | 2757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2758 | Value (variable length) | 2759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2760 The available fields are: 2762 TYPE - Topology TLVs have the following TYPE codes: 2763 Type High: 0x06 2764 Type Low: 2765 REQUEST_TYPE 0x01 2766 INTERNAL_TYPE 0x02 2767 EXTERNAL_TYPE 0x03 2769 Router Identifier (RID) - A 32-bit number provided by the router 2770 sourcing the information to uniquely identify it as the source. 2772 6.9.2 Wide Metric Encoding 2773 Multi-Protocol TLV's will provide an extendable section of metric 2774 information, which is not used for the primary routing compilation. 2775 Additional per path information is included to enable per-path cost 2776 calculations in the future. Use of the per-path costing along with the 2777 VID/TID will prove a complete solution for multidimensional routing. 2779 0 1 2 3 2780 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 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 | Offset | Priority | Reliability | Load | 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 | MTU | Hop-Count | 2785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2786 | Delay | 2787 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2788 | | | 2789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2790 | Bandwidth | 2791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2792 | Reserved | Opaque Flags | 2793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2794 | Extended Attributes | 2795 | (variable length) | 2796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 The fields are: 2799 Offset - Number of 16-bit words in the Extended Attribute section, 2800 used to determine the start of the destination information. A value of 2801 zero indicates no Extended Attributes are attached. 2803 Priority - Priority of the prefix when processing route. In an AS 2804 using priority values, a destination with a higher priority receives 2805 preferential treatment and is serviced before a destination with a 2806 lower priority. A value of zero indicates no priority is set. 2808 Reliability - The current error rate for the path. Measured as an 2809 error percentage. A value of 255 indicates 100% reliability 2811 Load - The load utilization of the path to the destination, measured 2812 as a percentage. A value of 255 indicates 100% load. 2814 MTU - The minimum maximum transmission unit size for the path to the 2815 destination. Not used in metric calculation, but available to 2816 underlying protocols 2818 Hop Count - The number of router traversals to the destination. 2820 Delay - The one-way latency along an unloaded path to the destination 2821 expressed in units of picoseconds per kilobit. This number is not 2822 scaled, a value of 0xFFFFFFFFFFFF indicates an unreachable route. 2824 Bandwidth - The path bandwidth measured in kilobit per second as 2825 presented by the interface. This number is not scaled, a value of 2826 0xFFFFFFFFFFFF indicates an unreachable route. 2828 Reserved - Transmitted as 0x0000 2830 Opaque Flags - 16-bit protocol specific flags. Values currently 2831 defined by Cisco are: 2832 OPAQUE_SRCWD 0x01 Route Source Withdraw 2833 OPAQUE_CD 0x02 Candidate default route 2834 OPAQUE_ACTIVE 0x04 Route is currently in active state 2835 OPAQUE_REPL 0x08 Route is replicated from another VRF 2837 Extended Attributes - (Optional) When present, defines extendable per 2838 destination attributes. This field is not normally transmitted. 2840 6.9.3 Extended Metrics 2841 Extended metrics allows for extensibility of the vector metrics in a 2842 manner similar to RFC 6390 [11]. Each Extended metric shall consist of 2843 a standard Type-Length header followed by application-specific 2844 information. Extended metrics values not understood must be treated as 2845 opaque and passed along with the associated route. 2847 The general formats for the Extended Metric fields are: 2848 0 1 2 3 2849 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 2850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2851 | Opcode | Offset | Data | 2852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2854 Opcode - Indicates the type of Extended Metric 2856 Offset - Number of 16-bit words in the sub-field. Offset does not 2857 include the length of the Opcode or offset fields) 2859 Data - Zero or more octets of data as defined by Opcode 2861 6.9.3.1 0x00 - NoOp 2862 This is used to pad the attribute section to ensure 32-bit alignment 2863 of the metric encoding section. 2865 0 1 2 3 2866 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 2867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2868 | 0x00 | 0x00 | 2869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2871 The fields are: 2872 Opcode - Transmitted as zero (0) 2874 Offset - Transmitted as zero (0) indicating no data is present 2876 Data - No data is present with this attribute. 2878 6.9.3.2 0x01 - Scaled Metric 2879 If a route is received from a back-rev neighbor, and the route is 2880 selected as the best path, the scaled metric received in the older 2881 UPDATE, may be attached to the packet. If received, the value is for 2882 informational purposes, and is not affected by K6 2884 0 1 2 3 2885 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 2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2887 | 0x01 | 0x04 | Reserved | 2888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2889 | Scaled Bandwidth | 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 | Scaled Delay | 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2894 Reserved - Transmitted as 0x0000 2896 Scaled Delay - An administrative parameter assigned statically on a 2897 per interface type basis to represent the time it takes along an 2898 unloaded path. This is expressed in units of 10s of microseconds 2899 divvied by 256. A delay of 0xFFFFFFFF indicates an unreachable route. 2901 Scaled Bandwidth - The minimum bandwidth along a path expressed in 2902 units of 2,560,000,000/kbps. A bandwidth of 0xFFFFFFFF indicates an 2903 unreachable route. 2905 6.9.3.3 0x02 - Administrator Tag 2906 This is used to provide and administrative tags for specific topology 2907 entries. It is not affected by K6 2909 0 1 2 3 2910 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 2911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2912 | 0x02 | 0x02 | Administrator Tag | 2913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2914 | Administrator Tag (cont) | 2915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2917 Administrator Tag - A tag assigned by the network administrator that 2918 is untouched by EIGRP. This allows a network administrator to filter 2919 routes in other EIGRP border routers based on this value. 2921 6.9.3.4 0x03 - Community List 2922 This is used to provide communities for specific topology entries. It 2923 is not affected by K6 2925 0 1 2 3 2926 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 2927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2928 | 0x03 | Offset | Community List | 2929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2930 | (variable length) | 2931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 Offset - Number of 16-bit words in the sub-field. Currently 2934 transmitted as 4 2936 Community List - One or more community values as defined in section 2937 6.4 2939 6.9.3.5 0x04 - Jitter 2940 0 1 2 3 2941 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 2942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2943 | 0x04 | 0x03 | Jitter | 2944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2945 | | 2946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2948 Jitter - The measure of the variability over time of the latency 2949 across a network measured in measured in microseconds. 2951 6.9.3.6 0x05 - Quiescent Energy 2952 0 1 2 3 2953 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 2954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2955 | 0x05 | 0x02 | Q-Energy (high) | 2956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2957 | Q-Energy (low) | 2958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2960 Q-Energy - Paths with higher idle (standby) energy usage will be 2961 reflected in a higher aggregate metric than those having lower energy 2962 usage. If present, this number will represent the idle power 2963 consumption expressed in milliwatts per kilobit. 2965 6.9.3.7 0x06 - Energy 2966 0 1 2 3 2967 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 2968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2969 | 0x06 | 0x02 | Energy (high) | 2970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2971 | Energy (low) | 2972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2974 Energy - Paths with higher active energy usage will be reflected in a 2975 higher aggregate metric than those having lower energy usage. If 2976 present, this number will represent the power consumption expressed in 2977 milliwatts per kilobit. 2979 6.9.3.8 0x07 - AddPath 2980 The Add Path enables EIGRP to advertise multiple best paths to 2981 adjacencies. There will be up to a maximum of 4 AddPath supported, 2982 where the format of the field will be as follows; 2984 0 1 2 3 2985 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 2986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2987 | 0x07 | Offset | AddPath (Variable Length) | 2988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2990 Offset - Number of 16-bit words in the sub-field. Currently 2991 transmitted as 4 2993 AddPath - Length of this field will vary in length based on whether it 2994 contains IPv4 or IPv6 data. 2996 6.9.3.8.1 AddPath with IPv4 Next-hop 2998 0 1 2 3 2999 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 3000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3001 | 0x07 | Offset | Next-hop Address(Upper 2 byes)| 3002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3003 | IPv4 Address (Lower 2 byes) | RID (Upper 2 byes) | 3004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3005 | RID (Upper 2 byes) | Admin Tag (Upper 2 byes) | 3006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3007 | Admin Tag (Upper 2 byes) |Extern Protocol| Flags Field | 3008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3010 Next Hop Address - IPv4 address is represented by 4 8-bit values 3011 (total 4 octets). If the value is zero(0), the IPv6 address from the 3012 received IPv4 header is used as the next-hop for the route. Otherwise, 3013 the specified IPv4 address will be used. 3015 Router Identifier (RID) - A 32-bit number provided by the router 3016 sourcing the information to uniquely identify it as the source. 3018 Admin Tag - A 32-bit administrative tag assigned by the network. This 3019 allows a network administrator to filter routes based on this value. 3021 If the route is of type external, then 2 addition bytes will be added 3022 as follows: 3023 External Protocol - Defines the external protocol that this route was 3024 learned. See Section 6.2 3026 Flag Field - See Section 6.8.1 3027 6.9.3.8.2 AddPath with IPv6 Next-hop 3028 0 1 2 3 3029 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 3030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3031 | 0x07 | Offset | Next-hop Address | 3032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3033 | | 3034 | (16 octets) | 3035 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 3036 | | RID (Upper 2 byes) | 3037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3038 | RID (Upper 2 byes) | Admin Tag (Upper 2 byes) | 3039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3040 | Admin Tag (Upper 2 byes) | Extern Protocol | Flags Field | 3041 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3043 Next Hop Address - IPv6 address is represented by 8 groups of 16-bit 3044 values (total 16 octets). If the value is zero(0), the IPv6 address 3045 from the received IPv6 header is used as the next-hop for the route. 3046 Otherwise, the specified IPv6 address will be used. 3048 Router Identifier (RID) - A 32-bit number provided by the router 3049 sourcing the information to uniquely identify it as the source. 3051 Admin Tag - A 32-bit administrative tag assigned by the network. This 3052 allows a network administrator to filter routes based on this value. 3053 If the route is of type external, then 2 addition bytes will be added 3054 as follows: 3056 External Protocol - Defines the external protocol that this route was 3057 learned. See Section 6.2 3059 Flag Field - See Section 6.8.1 3060 6.9.4 Exterior Encoding 3061 Additional routing information so provided for destinations outside of 3062 the EIGRP autonomous system as follows: 3063 0 1 2 3 3064 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 3065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3066 | Router Identification (RID) | 3067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3068 | Autonomous System Number (AS) | 3069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3070 | External Protocol Metric | 3071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3072 | Reserved |Extern Protocol| Flags Field | 3073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3075 Router Identifier (RID) - A 32-bit number provided by the router 3076 sourcing the information to uniquely identify it as the source. 3078 Autonomous System (AS) - 32-bit number indicating the external 3079 autonomous system the sending router is a member of. If the source 3080 protocol is EIGRP, this field will be the [VRID|AS] pair. 3082 External Protocol Metric 32-bit value of the metric used by the 3083 routing table as learned by the foreign protocol. If the External 3084 Protocol is IGRP or EIGRP, the value can (optionally) be 0, and the 3085 metric information is stored in the metric section. 3087 External Protocol - Defines the external protocol that this route was 3088 learned. See Section 6.2 3090 Flag Field - See Section 6.8.1 3092 6.9.5 Destination Encoding 3093 Destination information is encoded in Multi-Protocol packets in the 3094 same manner as used by Classic TLVs. This is accomplished by using a 3095 counter to indicate how many significant bits are present in the 3096 variable length address field 3097 0 1 2 3 3098 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 3099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3100 | Subnet Mask | Destination Address (variable length | 3101 | Bit Count | ((Bit Count - 1) / 8) + 1 | 3102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3104 Subnet Mask Bit Count - 8-bit value used to indicate the number of 3105 bits in the subnet mask. A value of 0 indicates the default network 3106 and no address is present. 3108 Destination Address - A variable length field used o carry the 3109 destination address. The length is determined by the number of 3110 consecutive bits in the destination address, rounded up to the nearest 3111 octet boundary, determines the length of the address. 3113 6.9.6 Route Information 3114 6.9.6.1 INTERNAL TYPE 3115 This TLV conveys destination information based on the IANA AFI defined 3116 in the TLV Header (See Section 6.9.1), and associated metric 3117 information. Routes advertised in this TLV are network interfaces that 3118 EIGRP is configured on as well as networks that are learned via other 3119 routers running EIGRP. 3121 6.9.6.2 EXTERNAL TYPE 3122 This TLV conveys destination information based on the IANA AFI defined 3123 in the TLV Header (See Section 6.9.1), and metric information for 3124 routes learned by other routing protocols that EIGRP injects into the 3125 AS. Available with this information is the identity of the routing 3126 protocol that created the route, the external metric, the AS number, 3127 an indicator if it should be marked as part of the EIGRP AS, and a 3128 network administrator tag used for route filtering at EIGRP AS 3129 boundaries. 3131 7 Security Considerations 3132 By the nature of being promiscuous, EIGRP will neighbor with any 3133 router that sends a valid HELLO packet. Due to security 3134 considerations, this "completely" open aspect requires policy 3135 capabilities to limit peering to valid routers. 3137 EIGRP does not rely on a PKI or a heavy weight authentication system. 3138 These systems challenge the scalability of EIGRP, which was a primary 3139 design goal. 3141 Instead, Denial of Service (DoS) attack prevention will depend on 3142 implementations rate-limiting packets to the control plane as well as 3143 authentication of the neighbor through the use of MD5 or SHA2-256 [6]. 3145 8 IANA Considerations 3147 This document serves as the sole reference for two multicast 3148 addresses; IGRP Routers [13], EIGRP Routers [14] and assignment for 3149 protocol number 88 (EIGRP) [15]. 3151 9 References 3153 9.1 Normative References 3154 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3155 Levels", BCP 14, RFC 2119, April 1997. 3156 [2] J.J. Garcia-Luna-Aceves, "A Unified Approach to Loop-Free Routing 3157 using Distance Vectors or Link States", 1989 ACM 089791-332- 3158 9/89/0009/0212, pages 212-223. 3159 [3] J.J. Garcia-Luna-Aceves, "Loop-Free Routing using Diffusing 3160 Computations", Network Information Systems Center, SRI International 3161 to appear in IEEE/ACM Transactions on Networking, Vol. 1, No. 1, 1993. 3162 [4] Rosen, E., "IANA Registries for BGP Extended Communities", RFC 3163 7153, March 2014. 3165 [5] Narten, T., "Assigning Experimental and Testing Numbers 3166 Considered Useful", RFC 3692, January 2004 3167 [6] Kelly, S., Frankel, S., "Using HMAC-SHA-256, HMAC-SHA-384, and 3168 HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 3169 [7] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 3170 August 1989 3171 [8] "DARPA Internet Protocol Specification", RFC 791, Sept 1981 3172 [9] [7] Deering, S., Hinden, R., "Internet Protocol, Version 6 3173 (IPv6) Specification", RFC 2460, December 1998 3175 9.2 Informative References 3176 [10] Moy, J., "OSPF Version 2" RFC 2328, 1998 3177 [11] Clark, A., Claise, B., "Guidelines for Considering New 3178 Performance Metric Development", RFC 6390, October 2011 3179 [12] Address Family Numbers, http://www.iana.org/assignments/address- 3180 family-numbers/address-family-numbers.xhtml 3181 [13] IPv4 Multicast Address Space Registry, 3182 http://www.iana.org/assignments/multicast-addresses 3183 [14] IPv6 Multicast Address Space Registry, 3184 http://www.iana.org/assignments/ipv6-multicast-addresses 3185 [15] Protocol Numbers, http://www.iana.org/assignments/protocol- 3186 numbers 3187 10 Acknowledgments 3188 This document was prepared using 2-Word-v2.0.template.dot. 3190 An initial thank you goes to Dino Farinacci, Bob Albrightson, and Dave 3191 Katz. Their significant accomplishments towards the design and 3192 development of the EIGRP protocol provided the bases for this 3193 document. 3195 A special and appreciative thank you goes to the core group of Cisco 3196 engineers whose dedication, long hours, and hard work lead the 3197 evolution of EIGRP over the following decade. They are Donnie Savage, 3198 Mickel Ravizza, Heidi Ou, Dawn Li, Thuan Tran, Catherine Tran, Don 3199 Slice, Claude Cartee, Donald Sharp, Steven Moore, Richard Wellum, Ray 3200 Romney, Jim Mollmann, Dennis Wind, Chris Van Heuveln, Gerald Redwine, 3201 Glen Matthews, Michael Wiebe, and others. 3203 The authors would like to gratefully acknowledge many people who have 3204 contributed to the discussions that lead to the making of this 3205 proposal. They include Chris Le, Saul Adler, Scott Van de Houten, 3206 Lalit Kumar, Yi Yang, Kumar Reddy, David Lapier, Scott Kirby, David 3207 Prall, Jason Frazier, Eric Voit, Dana Blair, Jim Guichard, and Alvaro 3208 Retana. 3210 In addition to the tireless work provided by the Cisco engineers over 3211 the years, I would like to personally recognize the teams what created 3212 Open Source versions of EIGRP; 3213 o Linux implementation developed by the Quagga team: Jan Janovic, 3214 Matej Perina, Peter Orsag, and Peter Paluch 3215 o BSD implementation developed, and release by, Renato Westphal 3217 Author's Address 3219 Donnie V Savage 3220 Cisco Systems, Inc 3221 7025 Kit Creed Rd, RTP, NC 3223 Phone: 919-392-2379 3224 Email: dsavage@cisco.com 3226 Donald Slice 3227 Cumulus Networks 3228 Apex, NC 3230 Phone: 3231 Email: dslice@cumulusnetworks.com 3233 James Ng 3234 Cisco Systems, Inc 3235 7025 Kit Creed Rd, RTP, NC 3237 Phone: 919-392-2582 3238 Email: jamng@cisco.com 3240 Peter Paluch 3241 University of Zilina 3242 Univerzitna 8215/1, Zilina 01026, Slovakia 3244 Phone: 421-905-164432 3245 Email: Peter.Paluch@fri.uniza.sk 3247 Steven Moore 3248 Cisco Systems, Inc 3249 7025 Kit Creed Rd, RTP, NC 3251 Phone: 919-392-2674 3252 Email: smoore@cisco.com 3254 Russ White 3255 LinkedIn 3256 Apex, NC 3258 Phone: 1-877-308-0993 3259 Email: russw@riw.us