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