idnits 2.17.1 draft-savage-eigrp-02.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 23) being 103 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 67 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1 Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6 Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 7 IANA Considerations' ) ** There are 117 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1874 has weird spacing: '... one of the ...' == Line 2386 has weird spacing: '...esented by 8...' == Line 2388 has weird spacing: '... as the next...' == Line 2389 has weird spacing: '...ss will be u...' == Line 2425 has weird spacing: '...esented by 8...' == (5 more instances...) -- The document date (10 April 2014) is 3666 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '4' on line 1739 looks like a reference -- Missing reference section? '1' on line 1731 looks like a reference -- Missing reference section? '3' on line 1736 looks like a reference -- Missing reference section? 'RFC3232' on line 202 looks like a reference -- Missing reference section? '7' on line 1746 looks like a reference -- Missing reference section? 'RFC2119' on line 1732 looks like a reference -- Missing reference section? '2' on line 1733 looks like a reference -- Missing reference section? 'RFC2234' on line 1734 looks like a reference -- Missing reference section? '5' on line 1824 looks like a reference -- Missing reference section? 'RFC4360' on line 1742 looks like a reference -- Missing reference section? '6' on line 2058 looks like a reference -- Missing reference section? 'RFC4868' on line 1743 looks like a reference -- Missing reference section? 'RFC1247' on line 1746 looks like a reference -- Missing reference section? '8' on line 2597 looks like a reference -- Missing reference section? 'RFC6390' on line 1750 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Savage 2 Internet-Draft D. Slice 3 Intended status: Informational J. Ng 4 Expires: October 2014 S. Moore 5 Cisco Systems 6 10 April 2014 7 R. White 8 Ericsson 9 10 April 2014 11 Enhanced Interior Gateway Routing Protocol 12 draft-savage-eigrp-02.txt 14 Abstract 16 This document describes the protocol design and architecture for 17 Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a 18 routing protocol based on Distance Vector technology. The specific 19 algorithm used is called DUAL, a Diffusing UPDATE Algorithm[4]. The 20 algorithm and procedures were researched, developed, and simulated by 21 SRI International. 23 Savage, et al. Expires October 10, 2014 [Page 1] 24 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference material 31 or to cite them other than as "work in progress. 33 Internet-Drafts are working documents of the Internet Engineering Task 34 Force (IETF). Note that other groups may also distribute working 35 documents as Internet-Drafts. The list of current Internet-Drafts is at 36 http://datatracker.ietf.org/drafts/current. 37 This document is not an Internet Standards Track specification; it is 38 published for informational purposes. 39 This Internet-Draft will expire on October 7, 2014 . 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (http://trustee.ietf.org/license- 48 info) in effect on the date of publication of this document. Please 49 review these documents carefully, as they describe your rights and 50 restrictions with respect to this document. Code Components extracted 51 from this document must include Simplified BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are provided 53 without warranty as described in the Simplified BSD License. 55 This document may not be modified, and derivative works of it may not 56 be created, except to format it for publication as an RFC or to 57 translate it into languages other than English. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC-2119 [1]. 65 Table of Contents 67 1 Introduction ....................................................... 6 68 2 Terminology ........................................................ 6 69 3 3 The DUAL Diffusing Update Algorithm .............................. 8 70 3.1 Algorithm Description .......................................... 8 71 3.2 3.2 Route States ............................................... 9 72 3.3 Feasibility Condition .......................................... 9 73 3.4 DUAL Message Types ............................................ 10 74 3.5 Dual Finite State Machine (FSM) ............................... 11 75 3.6 DUAL Operation - Example Topology ............................. 15 76 4 EIGRP Packets ..................................................... 17 77 4.1 UPDATE Packets ................................................ 17 78 4.2 QUERY Packets ................................................. 18 79 4.3 REPLY Packets ................................................. 18 80 4.4 Exception Handling ............................................ 18 81 4.4.1 Active Route Duration control.............................. 18 82 4.4.2 Stuck-in-Active............................................ 19 83 4.4.3 SIA-QUERY.................................................. 19 84 4.4.4 SIA-REPLY.................................................. 20 85 5 EIGRP Protocol Operation .......................................... 20 86 5.1 Finite State Machine .......................................... 20 87 5.2 Reliable Transport Protocol ................................... 20 88 5.2.1 Bandwidth on Low-Speed Links............................... 28 89 5.3 Neighbor Discovery/Recovery ................................... 28 90 5.3.1 Neighbor HoldTime.......................................... 28 91 5.3.2 HELLO Packets.............................................. 28 92 5.3.3 UPDATE Packets............................................. 29 93 5.3.4 Initialization Sequence.................................... 29 94 5.3.5 QUERY Packets During Neighbor Formation.................... 30 95 5.3.6 Neighbor Formation......................................... 31 96 5.3.7 Topology Table............................................. 31 97 5.3.8 Route Management........................................... 31 98 5.4 EIGRP Metric Coefficients ..................................... 32 99 5.4.1 Coefficients K1 and K2..................................... 33 100 5.4.2 Coefficients K3............................................ 33 101 5.4.3 Coefficients K4 and K5..................................... 33 102 5.4.4 Coefficients K6............................................ 34 103 5.4.4.1 Jitter ................................................ 34 104 5.4.4.2 Energy ................................................ 34 105 5.5 5.5 EIGRP Metric Calculations ................................. 35 106 5.5.1 Classic Metrics............................................ 35 107 5.5.1.1 Classic Composite Formulation ......................... 35 108 5.5.2 Wide Metrics............................................... 37 109 5.5.2.1 Wide Metric Vectors ................................... 37 110 5.5.2.2 Wide Metric Conversion Constants ...................... 38 111 5.5.2.3 Throughput Formulation ................................ 38 112 5.5.2.4 Latency Formulation ................................... 39 113 5.5.2.5 Composite Formulation ................................. 39 115 6 Security Considerations ........................................... 40 116 7 IANA Considerations ............................................... 40 117 8 References ........................................................ 40 118 8.1 Normative References .......................................... 40 119 8.2 Informative References ........................................ 40 120 9 Acknowledgments ................................................... 41 121 A EIGRP Packet Formats .............................................. 42 122 A.1 Protocol Number ............................................... 42 123 A.2 Protocol Assignment Encoding .................................. 42 124 A.3 Destination Assignment Encoding ............................... 42 125 A.4 EIGRP Communities Attribute ................................... 43 126 A.5 EIGRP Packet Header ........................................... 43 127 A.6 EIGRP TLV Encoding Format ..................................... 45 128 A.6.1 Type Field Encoding........................................ 46 129 A.6.2 Length Field Encoding...................................... 46 130 A.6.3 Value Field Encoding....................................... 46 131 A.7 EIGRP Generic TLV Definitions ................................. 46 132 A.7.1 0x0001 - PARAMETER_TYPE.................................... 46 133 A.7.2 0x0002 - AUTHENTICATION_TYPE............................... 47 134 A.7.2.1 0x02 - MD5 Authentication Type ........................ 47 135 A.7.2.2 0x03 - SHA2 Authentication Type ....................... 48 136 A.7.3 0x0003 - SEQUENCE_TYPE..................................... 48 137 A.7.4 0x0004 - SOFTWARE_VERSION_TYPE............................. 48 138 A.7.5 0x0005 - MULTICAST_SEQUENCE_TYPE........................... 48 139 A.7.6 0x0006 - PEER_INFORMATION_TYPE............................. 48 140 A.7.7 0x0007 - PEER_TERMAINATION_TYPE............................ 49 141 A.7.8 0x0008 - TID_LIST_TYPE..................................... 49 142 A.8 Classic Route Information TLV Types ........................... 49 143 A.8.1 Classic Flag Field Encoding................................ 49 144 A.8.2 Classic Metric Encoding.................................... 50 145 A.8.3 Classic Exterior Encoding.................................. 51 146 A.8.4 Classic Destination Encoding............................... 51 147 A.8.5 IPv4 Specific TLVs......................................... 52 148 A.8.5.1 IPv4 INTERNAL_TYPE .................................... 52 149 A.8.5.2 IPv4 EXTERNAL_TYPE .................................... 53 150 A.8.5.3 IPv4 COMMUNITY_TYPE ................................... 53 151 A.8.6 IPv6 Specific TLVs......................................... 54 152 A.8.6.1 IPv6 INTERNAL_TYPE .................................... 54 153 A.8.6.2 IPv6 EXTERNAL_TYPE .................................... 55 154 A.8.6.3 IPv6 COMMUNITY_TYPE ................................... 56 155 A.9 Multi-Protocol Route Information TLV Types .................... 57 156 A.9.1 TLV Header Encoding........................................ 57 157 A.9.2 Wide Metric Encoding....................................... 58 158 A.9.3 Extended Metrics........................................... 60 159 A.9.3.1 0x00 - NoOp ........................................... 60 160 A.9.3.2 0x01 - Scaled Metric .................................. 60 161 A.9.3.3 0x02 - Administrator Tag .............................. 61 162 A.9.3.4 0x03 - Community List ................................. 61 163 A.9.3.5 0x04 - Jitter ......................................... 62 164 A.9.3.6 0x05 - Quiescent Energy ............................... 62 166 A.9.3.7 0x06 - Energy .......................................... 62 167 A.9.3.8 0x07 - AddPath ......................................... 63 168 A.9.3.8.1 Addpath with IPv4 Next-hop ......................... 63 169 A.9.3.8.2 Addpath with IPv6 Next-hop .......................... 64 170 A.9.4 Exterior Encoding........................................... 65 171 A.9.5 Destination Encoding........................................ 65 172 A.9.6 Route Information........................................... 66 173 A.9.6.1 INTERNAL TYPE .......................................... 66 174 A.9.6.2 EXTERNAL TYPE .......................................... 66 176 1 Introduction 177 This document describes the Enhanced Interior Gateway Routing 178 Protocol (EIGRP), routing protocol designed and developed by Cisco 179 Systems. The convergence technology is based on research conducted at 180 SRI International. The Diffusing Update Algorithm (DUAL) is the 181 algorithm used to obtain loop-freedom at every instant throughout a 182 route computation[3]. This allows all routers involved in a topology 183 change to synchronize at the same time; the routers not affected by 184 topology changes are not involved in the recalculation. This document 185 describes the protocol that implements these functions. 187 2 Terminology 188 The following list describes acronyms and definitions for terms used 189 throughout this document: 191 EIGRP 192 Enhanced Interior Gateway Routing Protocol. 194 Active state 195 A route that is currently in an unresolved or un-converged state. 196 The term active is used because the router is actively attempting to 197 compute an SDAG. 199 Address Family Identifier (AFI) 200 A term used to describe an address encoding in a packet. An 201 address family currently pertains to an IPv4 or IPv6 address. See 202 [RFC3232] for details. 204 Autonomous System (AS) 205 A routing sub-domain representing a logical set of network 206 segments and attached devices. 208 Base Topology 209 The entire network itself, for which the usual set of routes is 210 calculated, is known as the base topology. The base topology (or 211 underlying network) is characterized by the Network Layer 213 Reachability Information (NLRI) that a router uses to calculate 214 the global routing table to make routing and forwarding 215 decisions. 217 Downstream Router 218 A router that is one or more hops away, in the direction of th 219 destination. 221 Diffusing UPDATE Algorithm (DUAL) 222 A loop-free routing algorithm used with distance vectors or link 223 states that provides a diffused computation of a routing table. It 224 works very well in the presence of multiple topology changes with low 225 overhead. The technology was researched and developed at SRI 226 International. 228 Feasibility Condition 229 The feasibility condition for a neighbor is met when the 230 neighbor's Reported Distance is less than the Feasible Distance. This 231 is the Source Node Condition (SNC) cited in reference [4]. 233 Feasible Successor 234 A route describing reachability through a specific neighbor that 235 meets the feasibility condition. 237 Neighbor / Peer 238 Two routers with interfaces connected to a common subnet are 239 known as adjacent neighbors. Two routers that are multiple hops apart 240 on a common subnet are known as remote neighbors. Neighbors 241 dynamically discover each other and exchange EIGRP protocol messages. 242 Each router maintains a topology table containing information learned 243 from each of its neighbors. 245 Passive state 246 A route is considered in passive state when there are one or more 247 minimal cost feasible successors that can reach a destination. The 248 term passive is used because the router is not actively computing a 249 shortest path SDAG for this destination. A route in passive state is 250 usable for forwarding data packets. 252 PE Router / Provider Edge Router 253 This is the device that logically sits on the provider side of 254 the provider/customer demarcation in a network topology. 256 Routing Information Base (RIB) / Routing Table 257 A table where a router stores network destinations associated 258 with a next-hop to reach particular network destinations and the 259 metric associated with the route. 261 Subsequent-Address Family Identifier (SAFI) 262 Unicast and Multicast are examples of a Subsequent-Address Family 263 Identifier. 265 Successor Directed Acyclic Graph (SDAG) 266 When a route to a destination becomes unreachable, it is required 267 that a router computes a directed graph with respect to the 268 destination. This decision requires the router to select from the 269 neighbor's topology table a feasible successor. 271 Sub-Topology 272 A sub-topology is characterized by an independent set of router 273 and links in a network, for which EIGRP performs an independent path 274 calculations. This allows each sub-topology to implement class- 275 specific topologies to carry class specific traffic. 277 Successor 278 The unique neighboring router that has met the feasibility 279 condition, and has been selected as the next-hop for forwarding 280 packets. 282 Topology Identifier (TID) 283 A number that is used to mark prefixes as belonging to a specific 284 sub-topology. 286 Type, Length, Value(TLV) 287 An encoding format used by EIGRP. Each attribute present in a 288 routing packet is tagged. The tag determines the type and length of 289 information in the value portion of the attribute. This format allows 290 extensibility and backward compatibility 292 Upstream Router 293 Any router that is one or multiple hops in the direction of the 294 source of the information. 296 Reported Distance (RD) 297 Total metric along a path to a destination network as advertised 298 by a neighbor. 300 Feasible Distance (FD) 301 Defined as the lowest known total metric to a destination network 302 from the current router since the last transition from Active to 303 Passive state. Being effectively a record of the smallest known 304 metric since the last time the network entered the Passive state, the 305 FD is not necessarily a metric of the current best path. Exactly one 306 Feasible Distance is computed per destination network. 308 3 3 The DUAL Diffusing Update Algorithm 309 The Diffusing Update Algorithm (DUAL) provides a loop-free path 310 through a network made up of nodes and edges (routers and links) at 311 every instant throughout a route computation. This allows all 312 involved in a topology change to compute a best path in a distributed 313 (diffusing) way, so calculations are performed in parallel. Routers 314 that are not affected by topology changes are not involved in the 315 recalculation. The convergence time with DUAL rivals that of any 316 other existing routing protocol. 318 3.1 Algorithm Description 319 DUAL is used by EIGRP to achieve fast loop-free convergence with 320 little cost overhead, allowing EIGRP to provide convergence rates 321 comparable, and in some cases better than, most common link state 322 protocols[7]. "Only nodes that are affected by a topology change need 323 to propagate and act on information about the topology change, 324 allowing EIGRP to have good scaling properties, reduced overhead, and 325 lower complexity than many other interior gateway protocols. 327 Distributed routing algorithms are required to propagate information 328 as well as coordinate information among all nodes in the network. 329 Unlike Bellman-Ford distance vector protocols, DUAL uses an approach 330 to propagation of routing information with feedback known as 331 diffusing computations. The diffusing computation grows by including 332 nodes that are affected by the topology change and shrinks by 333 excluding ones that are not. This allows the computation to 334 dynamically adjust in scope and terminate as soon as possible. 336 3.2 3.2 Route States 337 A topology table entry for a destination can have one of two states, 338 Passive and Active. A route transitions its state when there is a 339 topology change in the network. This can be caused by link failure, 340 node failure, or a link cost increase. The two states are as follow: 342 o Passive 343 A route is considered in the Passive state when a router is not 344 performing a route recalculation. When a route is in passive 345 state it is usable and the next hop is perceived to be downstream 346 of the destination. 348 o Active 349 A destination is in Active state when a router is computing a 350 Successor Directed Acyclic Graph (SDAG) for the destination. 352 While a router has a route in active state, it records the new metric 353 information but does not make any routing decisions until it goes 354 back to passive state. A route goes from active state to passive 355 state when a router receives responses from all of its neighbors and 356 the diffusing computation is complete. 357 If an alternate loop free path exists for the route, the neighbor 358 WILL NOT go into the Active state avoiding a route recalculation. 359 When there are no feasible successors, a route goes into Active state 360 and a route recalculation must occur. 362 3.3 Feasibility Condition 363 The feasibility condition is a part of DUAL that allows the diffused 364 computation to terminate as early as possible. Nodes that are not 365 affected by the topology change are not required to perform a DUAL 366 computation and may not be aware a topology change occurred. If 367 informed about a topology change, a router may keep a route in 368 passive state if it is aware of other paths that are downstream 369 towards the destination (routes meeting the feasibility condition). A 370 route that meets the feasibility condition is determined to be loop- 371 free and downstream along the path between the router and the 372 destination. 374 In order to facilitate describing the feasibility condition, a few 375 definitions are in order. 377 o A Successor for a given route is the next-hop used to forward 378 data traffic for a destination. Typically the successor is chosen 379 based on the least cost path to reach the destination. 381 o A Feasible Successor is a neighbor that meets the feasibility 382 condition. A feasible successor is regarded as a downstream neighbor 383 towards the destination but it may not be the least cost path, but 384 could still be used for forwarding data packets in the event equal or 385 unequal cost load sharing was active. A feasible successor can become 386 a successor when the current successor becomes unreachable. 388 o The Feasibility Condition is met when a neighbor's advertised 389 cost, (RD) to a destination is less than the Feasible Distance for 390 that destination, or in other words, the Feasibility Condition is met 391 when the neighbor is closer to the destination than the router itself 392 has ever been since the destination has entered the Passive state for 393 the last time. 395 A neighbor that advertises a route with a cost that does not meet the 396 feasibility condition may be upstream and thus cannot be guaranteed 397 to be the next hop for a loop free path. Routes advertised by 398 upstream neighbors are not recorded in the routing table but saved in 399 the topology table. 401 3.4 DUAL Message Types 402 The Dual algorithm operates with three basic message types, Queries, 403 Updates, and Replies: 405 o UPDATE - sent to indicate a change in metric or an addition of a 406 destination. 408 o QUERY - sent when feasibility condition fails which can happen 409 for reasons like a destination becoming unreachable, or the metric 410 increasing to a value greater than its current Feasible Distance. 412 o REPLY - sent in response to a QUERY or SIA-QUERY 414 When in passive state, a received query may be propagated if there 415 are no feasible successors found. If a feasible successor is found, 416 the query is not propagated and a reply is sent for the destination 417 with a metric equal to the current routing table metric. When a query 418 is received from a non-successor in active state a reply is sent and 419 the query is not propagated. The reply for the destination contains a 420 metric equal to the current routing table metric. 422 3.5 Dual Finite State Machine (FSM) 423 The DUAL finite state machine embodies the decision process for all 424 route computations. It tracks all routes advertised by all neighbors. 425 The distance information, known as a metric, is used by DUAL to 426 select efficient loop free paths. DUAL selects routes to be inserted 427 into a routing table based on feasible successors. A successor is a 428 neighboring router used for packet forwarding that has least cost 429 path to a destination that is guaranteed not to be part of a routing 430 loop. 431 When there are no feasible successors but there are neighbors 432 advertising the destination, a recalculation must occur to determine 433 a new successor. 435 The amount of time it takes to calculate the route impacts the 436 convergence time. Even though the recalculation is not processor- 437 intensive, it is advantageous to avoid recalculation if it is not 438 necessary. When a topology change occurs, DUAL will test for feasible 439 successors. If there are feasible successors, it will use any it 440 finds in order to avoid any unnecessary recalculation. 442 The finite state machine, which applies per destination in the 443 topology table, operates independently for each destination. It is 444 true that if a single link goes down, multiple routes may go into 445 active state. However, a separate Successor Directed Acyclic Graph 446 (SDAG) is computed for each destination, so loop-free topologies can 447 be maintained. Figure 1 illustrates the FSM: 449 i Node that is computing route. 450 j Destination node or network. 451 K Any neighbor of node i. 452 oij QUERY origin flag 453 0 = metric increase during active state 454 1 = node i originated 455 2 = QUERY from, or link increase to, successor during active state 456 3 = QUERY originated from successor. 457 rijk REPLY status flag for each neighbor k for destination j, 458 1 = awaiting REPLY, 459 0 = received REPLY. 460 lik The link connecting node i to neighbor k. 461 FS Feasible Successor 463 +------------+ +-----------+ 464 | \ / | 465 | \ / | 466 | +=================================+ | 467 | | | | 468 |(1)| Passive |(2)| 469 +-->| |<--+ 470 +=================================+ 471 ^ | ^ ^ ^ | 472 (14)| |(15)| |(13)| | 473 | (4)| |(16)| | (3)| 474 | | | | | +----------+ 475 | | | | | \ 476 +-------+ + + | +-----------+ \ 477 / / / | \ \ 478 / / / +----+ \ \ 479 | | | | | | 480 | v | | | v 481 +==========+(11) +==========+ +==========+(12) +==========+ 482 | Active |---->| Active |(5) | Active |---->| Active | 483 | | (9)| |---->| | (10)| | 484 | Oij=0 |<----| Oij=1 | | Oij=2 |<----| Oij=3 | 485 +--| | +--| | +--| | +--| | 486 | +==========+ | +==========+ | +==========+ | +==========+ 487 | ^ |(5) | ^ | ^ ^ | ^ 488 | | +-----|------|---------|----+ | | | 489 +------+ +------+ +---------+ +---------+ 490 (6,7,8) (6,7,8) (6,7,8) (6,7,8) 492 Figure 1 - DUAL Finite State Machine 494 The following describes in detail the state/event/action transitions 495 of the DUAL FSM. For all steps, the topology table is updated with 496 the new metric information from either; QUERY, REPLY, or UPDATE 497 received. 499 (1) A QUERY is received from a neighbor that is not the current 500 successor. The route is currently in passive state. A feasible 501 successor exists since the successor was not affected, so the route 502 remains in passive state. Since a feasible successor exists, a REPLY 503 is required to be sent back to the originator of the QUERY. Any 504 metric received in the QUERY from that neighbor is recorded in the 505 topology table and FC is run to check for any change to current 506 successor. 508 (2) A directly connected interface changes state (connects, 509 disconnects, or changes metric). Or similarly, an UPDATE or QUERY has 510 been received with a metric change for an existing destination. The 511 route will stay in the active state if the current successor is not 512 affected by the change, or it is no longer reachable and there is a 513 feasible successor. In either case, an UPDATE is sent with the new 514 metric information, if it had changed. 516 (3) A QUERY was received from a neighbor who is the current successor 517 and no feasible successors exist. The route for the destination goes 518 into active state. A QUERY is sent to all neighbors on all 519 interfaces. The QUERY origin flag is set to indicate the QUERY 520 originated from a neighbor marked as successor for route. The REPLY 521 status flag is set for all neighbors to indicate outstanding replies. 523 (4) A directly connected link has gone down or its cost has 524 increased, or an UPDATE has been received with a metric increase. The 525 route to the destination goes to active state if there are no 526 feasible successors found. A QUERY is sent to all neighbors on all 527 interfaces. The QUERY origin flag is to indicate that the router 528 originated the QUERY. The REPLY status flag is set to 1 for all 529 neighbors to indicate outstanding replies. 531 (5) While a route for a destination is in active state, and a QUERY 532 is received from the current successor, the route remains active. The 533 QUERY origin flag is set to indicate that there was another topology 534 change while in active state. This indication is used so new feasible 535 successors are compared to the metric which made the route go to 536 active state with the current successor. 538 (6) While a route for a destination is in active state and a QUERY is 539 received from a neighbor that is not the current successor, a REPLY 540 should be sent to the neighbor. The metric advertised in the QUERY 541 should be recorded. 543 (7) If a link cost change or an update with a metric change is 544 received in active state from a non-successor, the router stays in 545 active state for the destination. The metric information in the 546 update is recorded. When a route is in the active state, a QUERY and 547 UPDATE is never sent. 549 (8) If a REPLY for a destination, in active state, is received from a 550 neighbor or the link between a router and the neighbor fails, the 551 router records that the neighbor replied to the QUERY. The REPLY 552 status flag is set to 0 to indicate this. The route stays in active 553 state if there are more replies pending. The router has not heard 554 from all neighbors. 556 (9) If a route for a destination is in active state, and a link fails 557 or a cost increase occurred between a router and its successor, the 558 router treats this case like it has received a REPLY from its 559 successor. When this occurs after the router originates a QUERY, it 560 sets QUERY origin flag to indicate that another topology change 561 occurred in active state. 563 (10) If a route for a destination is in active state, and a link 564 fails or a cost increase occurred between a router and its successor, 565 the router treats this case like it has received a REPLY from its 566 successor. When this occurs after a successor originated a QUERY, the 567 router sets the QUERY origin flag to indicate that another topology 568 change occurred in active state. 570 (11) If a route for a destination is in active state and a link cost 571 increase to the successor occurred, and the last REPLY was received 572 from all neighbors, but there is no feasible successor, the route 573 should stay in active state. A QUERY is sent to all neighbors. The 574 QUERY origin flag is set to 1. 576 (12) If a route for a destination is in active state because of a 577 QUERY received from the current successor, and the last REPLY was 578 received from all neighbors, but there is no feasible successor, the 579 route should stay in active state. A QUERY is sent to all neighbors. 580 The QUERY origin flag is set to 3. 582 (13) Received replies from all neighbors. Since the QUERY origin flag 583 indicates the successor originated the QUERY, it transitions to 584 passive state and sends a REPLY to the old successor. 586 (14) Received replies from all neighbors. Since the QUERY origin flag 587 indicates a topology change to the successor while in active state, 588 it need not send a REPLY to the old successor. When the feasibility 589 condition is met, the route state transitions to passive. 591 (15) Received replies from all neighbors. Since the QUERY origin flag 592 indicates either the router itself originated the QUERY or FC was not 593 satisfied with the replies received in ACTIVE state, FD is reset to 594 infinite value and the minimum of all the reported metrics is chosen 595 as FD and route transitions back to PASSIVE state. A REPLY is sent to 596 the old-successor if Oij flags indicate that there was a QUERY from 597 successor. 599 (16) If a route for a destination is in active state because of a 600 QUERY received from the current successor or there was an increase in 601 Distance while in ACTIVE state, the last REPLY was received from all 602 neighbors, and a feasible successor exists for the destination, the 603 route can go into passive state and a REPLY is sent to successor if 604 Oij indicates that QUERY was received from successor. 606 3.6 DUAL Operation - Example Topology 607 The following topology (Figure 2) will be used to provide an example 608 of how DUAL is used to reroute after a link failure. Each node is 609 labeled with its costs to destination N. The arrows indicate the 610 successor (next-hop) used to reach destination N. The least cost path 611 is selected. 613 N 614 | 615 (1)A ---<--- B(2) 616 | | 617 ^ | 618 | | 619 (2)D ---<--- C(3) 621 Figure 2 - Stable Topology 623 Now consider the case where the link between A and D fails (Figure 624 3). Only observing destination provided by node N, D enters the 625 active state and sends a QUERY to all its neighbors, in this case 626 node C. 627 C determines that it has a feasible successor and replies 628 immediately with metric 3. 629 C changes its old successor of D to its new single successor B and 630 the route to N stays in passive state. 631 D receives the REPLY and can transition out of active state since 632 it received replies from all its neighbors. 633 D now has a viable path to N through C. 634 D elects C as its successor to reach node N with a cost of 4. 636 Notice that node A and B were not involved in the recalculation since 637 they were not affected by the change. 639 N N 640 | | 641 A ---<--- B A ---<--- B 642 | | | | 643 X | ^ | 644 | | | | 645 D ---<--- C D ---<--- C 646 Q-> <-R 647 N 648 | 649 (1)A ---<--- B(2) 650 | 651 ^ 652 | 653 (4)D --->--- C(3) 655 Figure 3 - Link between A and D fails 657 Let's consider the situation in Figure 4, where feasible successors 658 may not exist. If the link between node A and B fails, B goes into 659 active state for destination N since it has no feasible successors. 660 Node B sends a QUERY to node C. C has no feasible successors, so it 661 goes active for destination N and sends QUERY to B. B replies to the 662 QUERY since it is in active state. 664 Once C has received this reply, it has heard from all its neighbors, 665 so it can go passive for the unreachable route. As C removes the (now 666 unreachable) destination from its table, C sends REPLY to its old 667 successor. B receives this reply from C, and determines this is the 668 last REPLY it is waiting on before determining what the new state of 669 the route should be; on receiving this reply, B deletes the route to 670 N from its routing table. 672 Since B was the originator of the initial QUERY it does not have to 673 send a REPLY to its old successor (it would not be able to any ways, 674 because the link to its old successor is down). Note that nodes A and 675 D were not involved in the recalculation since their successors were 676 not affected. 678 N N 679 | | 680 (1)A ---<--- B(2) A ------- B Q 681 | | | | |^ ^ 682 ^ ^ ^ | || | 683 | | | | v| | 684 (2)D C(3) D C Ack R 686 Figure 4 687 No Feasible Successors when link between A and B fails 689 4 EIGRP Packets 690 EIGRP uses 5 different packet types to operate. 692 HELLO/Ack Packets 693 QUERY Packets (includes SIA-Query) 694 UPDATE Packets 695 REPLY Packets (includes SIA-Reply) 697 EIGRP packets will be encapsulated in the respective network layer 698 protocol that it is supporting. Since EIGRP is potentially capable of 699 running in an integrated mode the encapsulation is not specified. 701 Support for network layer protocol fragmentation is supported, though 702 EIGRP will attempt to avoid maximum size packets that exceed the 703 interface MTU by sending multiple packets which are less than or 704 equal to MTU sized packets. 706 Each packet transmitted will use either multicast or unicast network 707 layer destination addresses. When multicast addresses are used a 708 mapping for the data link multicast address (when available) must be 709 provided. The source address will be set to the address of the 710 sending interface, if applicable. The following network layer 711 multicast addresses and associated data link multicast addresses will 712 be used. 714 IPv4 - 224.0.0.10 715 IPv6 - FF02:0:0:0:0:0:0:A 717 The above data link multicast addresses will be used on multicast 718 capable media, and will be media independent for unicast addresses. 719 Network layer addresses will be used and the mapping to media 720 addresses will be achieved by the native protocol mechanisms. 722 4.1 UPDATE Packets 723 UPDATE packets are used to convey destinations, and the reachability 724 of the destinations. When a new neighbor is discovered, unicast 725 UPDATE packets are used to transmit a full table to the new neighbor, 726 so the neighbor can build up its topology table. In normal operation 727 (other than neighbor startup such as a link cost changes), UPDATE 728 packets are multicast. UPDATE packets are always transmitted 729 reliably. Each TLV destination will be processed individually through 730 the DUAL state machine. 732 4.2 QUERY Packets 733 A QUERY packet sent by a router advertises that a route is in active 734 state and the originator is requesting alternate path information 735 from its neighbors. An infinite metric is encoded by setting the 736 Delay part of the metric to its maximum value. 738 If there is a topology change that causes multiple destinations to go 739 unreachable, EIGRP will build a single QUERY packet with all 740 destinations present. The state of each route is recorded 741 individually, so a responding QUERY or REPLY need not contain all the 742 same destinations in a single packet. Since the packets are 743 guaranteed reliable all route QUERY packets are guaranteed reliable. 745 When a QUERY packet is received, each destination will trigger a DUAL 746 event and the state machine will run individually for each route. 747 Once the entire original QUERY packet is processed, then a REPLY or 748 SIA-REPLY will be sent with the latest information. 750 4.3 REPLY Packets 751 A REPLY packet will be sent in response to a QUERY or SIA-QUERY 752 packet, if the router believes it has an alternate feasible 753 successor. The REPLY packet will include a TLV for each destination 754 and the associated vectorized metric in its own topology table. 756 The REPLY packet is sent after the entire received QUERY packet is 757 processed. When a REPLY packet is received, there is no reason to 758 process the packet before an acknowledgment is sent. Therefore, an 759 Ack packet is sent immediately and then the packet is processed. 761 Each TLV destination will be processed individually through the DUAL 762 state machine. When a query is received for a route that doesn't 763 exist in our topology table, a reply with infinite metric is sent and 764 an entry in the topology table is added with the metric in the QUERY 765 if the metric is not an infinite value. 767 4.4 Exception Handling 768 4.4.1 Active Route Duration control 769 When an EIGRP router transitions to ACTIVE state for a particular 770 destination a QUERY is sent to all neighbors and the ACTIVE timer is 771 started to limit the amount of time a destination may remain in an 772 active state. The default time DUAL is allowed to stay active, trying 773 to resolve a path to a destination, is a maximum of six (6) minutes. 775 This is broken into an initial 90 seconds period following the QUERY, 776 and up to 3 additional "busy" periods in which a SIA-QUERY is sent. 777 Failure to respond to a SIA-QUERY with in the 90 second will result 778 in the neighbor being declared in the Stuck In Active (SIA) state. 780 4.4.2 Stuck-in-Active 781 A route is regarded as Stuck-In-Active (SIA) when DUAL does not 782 receive a reply to the active process. This process is begun when a 783 QUERY is sent by. After the initial 90 seconds, the router will send 784 a SIA-QUERY, this must be replied to with either a REPLY or SIA- 785 REPLY. Failure of a neighbor to send either a REPLY or SIA-REPLY 786 with-in the 90 seconds will result in the neighbor being deemed to be 787 in an SIA state. If the SIA state is declared, DUAL will then delete 788 all routes from that neighbor and resets adjacency with that 789 neighbor, acting as if the neighbor had responded with an unreachable 790 message for all routes. 791 4.4.3 SIA-QUERY 792 When a QUERY is still outstanding and awaiting a REPLY from a 793 neighbor, there is insufficient information to determine why a REPLY 794 has not been received. A lost packet, congestion on the link, or a 795 slow neighbor could cause a lack of REPLY from a downstream neighbor. 797 In order to attempt to ascertain if the neighbor device is still 798 attempting to converge on the active route, an EIGRP router MAY send 799 a SIA-QUERY packet to the active neighbors. This enables an EIGRP 800 router to determine if there is a communication issue with the 801 neighbor, or it is simply still attempting to converge with 802 downstream routers. 804 By sending a SIA-QUERY, the originating router may extend the 805 effective active time by resetting the Active timer which has been 806 previously set and thus allow convergence to continue so long as 807 neighbor devices successfully communicate that convergence is still 808 underway. 810 The SIA-QUERY packet SHOULD be sent on a per-destination basis at 811 one-half of the Active timeout period. Up to three SIA-QUERY packets 812 for a specific destination may be sent, each at a value of one-half 813 the Active time, so long as each are successfully acknowledged and 814 met with a SIA-REPLY. 816 Upon receipt of a SIA-QUERY packet, and EIGRP router should first 817 send an ACK and then continue to process the SIA-QUERY information. 818 The QUERY is sent on a per-destination basis at approximately one- 819 half the active time. 821 If the EIGRP router is still active for the destination specified in 822 the SIA-QUERY, the router SHOULD respond to the originator with the 823 SIA-REPLY indicating that active processing for this destination is 824 still underway by setting the Active flag in the packet upon 825 response. 827 If the router receives a SIA-QUERY referencing a destination for 828 which it has not received the original QUERY, the router SHOULD treat 829 the packet as though it was a standard QUERY: 831 1) Acknowledge the receipt of the packet 832 2) Send a REPLY if a Successor exists 833 3) If the QUERY is from the successor, transition to the Active 834 state if and only if feasibility-condition fails and send a SIA-REPLY 835 with the Active bit set 837 4.4.4 SIA-REPLY 838 A SIA-REPLY packet is the corresponding response upon receipt of a 839 SIA-QUERY from an EIGRP neighbor. The SIA-REPLY packet will include a 840 TLV for each destination and the associated metric for which is 841 stored in its own routing table. The SIA-REPLY packet is sent after 842 the entire received SIA-QUERY packet is processed. 844 If the EIGRP router is still ACTIVE for a destination, the SIA-REPLY 845 packet will be sent with the ACTIVE bit set. This confirms for the 846 neighbor device that the SIA-QUERY packet has been processed by DUAL 847 and that the router is still attempting to resolve a loop-free path 848 (likely awaiting responses to its own QUERY to downstream neighbors). 850 The SIA-REPLY informs the recipient that convergence is complete or 851 still ongoing, however; it is an explicit notification that the 852 router is still actively engaged in the convergence process. This 853 allows the device that sent the SIA-QUERY to determine whether it 854 should continue to allow the routes that are not converged to be in 855 the ACTIVE state, or if it should reset the neighbor relationship and 856 flush all routes through this neighbor. 858 5 EIGRP Protocol Operation 859 EIGRP has four basic components: 860 o Finite State Machine 861 o Reliable Transport Protocol 862 o Neighbor Discovery/Recovery 863 o Route Management 865 5.1 Finite State Machine 866 The detail of DUAL, the State Machine used by EIGRP is covered in 867 Section 3 869 5.2 Reliable Transport Protocol 870 The reliable transport is responsible for guaranteed, ordered 871 delivery of EIGRP packets to all neighbors. It supports intermixed 872 transmission of multicast or unicast packets. Some EIGRP packets must 873 be transmitted reliably and others need not. For efficiency, 874 reliability is provided only when necessary. 876 For example, on a multi-access network that has multicast 877 capabilities, such as Ethernet, it is not necessary to send HELLOs 878 reliably to all neighbors individually. EIGRP sends a single 879 multicast HELLO with an indication in the packet informing the 880 receivers that the packet need not be acknowledged. Other types of 881 packets, such as UPDATE packets, require acknowledgment and this is 882 indicated in the packet. The reliable transport has a provision to 883 send multicast packets quickly when there are unacknowledged packets 884 pending. This helps insure that convergence time remains low in the 885 presence of varying speed links. 887 The DUAL Algorithm assumes there is lossless communication between 888 devices and thus must rely upon the transport protocol to guarantee 889 that messages are transmitted reliably. EIGRP implements the Reliable 890 Transport Protocol to ensure ordered delivery and acknowledgement of 891 any messages requiring reliable transmission. State variables such as 892 a received sequence number, acknowledgment number, and transmission 893 queues MUST be maintained on a per neighbor basis. 895 The following sequence number rules must be met for the reliable 896 EIGRP protocol to work correctly: 898 o A sender of a packet includes its global sequence number 899 in the sequence number field of the fixed header. The 900 sender includes the receivers sequence number in the 901 acknowledgment number field of the fixed header. 902 o Any packets that do not require acknowledgment must be 903 sent with a sequence number of 0. 904 o Any packet that has an acknowledgment number of zero (0) 905 indicates that sender is not expecting to explicitly 906 acknowledging delivery. Otherwise, it is acknowledging 907 a single packet. 908 o Packets that are network layer multicast must contain 909 acknowledgment number of 0. 911 When a router transmits a packet, it increments its sequence number 912 and marks the packet as requiring acknowledgment by all neighbors on 913 the interface for which the packet is sent. When individual 914 acknowledgments are unicast addressed by the receivers to the sender 915 with the acknowledgment number equal to the packets sequence number, 916 the sender SHALL clear the pending acknowledgement requirement for 917 the packet from the respective neighbor. 919 If the required acknowledgement is not received for the packet, it 920 MUST be retransmitted. Retransmissions will occur for a maximum of 5 921 seconds. This retransmission for each packet is tried 16 times after 922 which if there is no ACK, neighborship is reset with that peer which 923 didn't send the ACK. 925 The protocol has no explicit windowing support. A receiver will 926 acknowledge each packet individually and will drop packets that are 927 received out of order. Duplicate packets are also discarded upon 928 receipt. Acknowledgments are not accumulative. Therefore an ACK with 929 a non-zero sequence number acknowledges a single packet. 931 There are situations when multicast and unicast packets are 932 transmitted close together on multi-access broadcast capable 933 networks. The reliable transport mechanism MUST assure that all 934 multicasts are transmitted in order as well as not mixing the order 935 among unicasts and multicast packets. The reliable transport provides 936 a mechanism to deliver multicast packets in order to some receivers 937 quickly, while some receivers have not yet received all unicast or 938 previously sent multicast packets. The SEQUENCE_TYPE TLV in HELLO 939 packets achieves this. This will be explained in more detail in this 940 section. 942 Figure 5 illustrates the reliable transport protocol on point-to- 943 point links. There are two scenarios that may occur, an UPDATE 944 initiated packet exchange, or a QUERY initiated packet exchange. This 945 example will assume no packet loss. 947 Router A Router B 948 An UPDATE Exchange 949 <---------------- 950 UPDATE (multicast) 951 A receives packet Seq=100, Ack=0 952 Queues pkt on A's retrans list 953 ----------------> 954 ACK (unicast) 955 Seq=0, Ack=100 Receives Ack 956 Process Update Dequeue pkt from A's retrans list 958 A QUERY Exchange 959 <---------------- 960 QUERY (multicast) 961 A receives packet Seq=101, Ack=0 962 Process QUERY Queues pkt on A's retrans list 964 ----------------> 965 REPLY (unicast) 966 Seq=201, Ack=101 Process Ack 967 Dequeue pkt from A's retrans list 968 Process REPLY pkt 969 <---------------- 970 ACK (unicast) 971 A receives packet Seq=0, Ack=201 973 Figure 5 - Reliable Transfer on point-to-point links 975 Savage, et al. Expires October 10, 2014 [Page 22] 976 The UPDATE exchange sequence requires UPDATE packets sent to be 977 delivered reliably. The UPDATE packet transmitted contains a sequence 978 number that is acknowledged by a receipt of an Ack packet. If the 979 UPDATE or the Ack packet is lost on the network, the UPDATE packet 980 will be retransmitted. 982 Figure 6 illustrates the situation where there is heavy packet loss 983 on a network. 985 Router A Router B 986 <---------------- 987 UPDATE (multicast) 988 A receives packet Seq=100, Ack=0 989 Queues pkt on A's retrans list 990 ----------------> 991 ACK (unicast) 992 Seq=0, Ack=100 Receives Ack 993 Process Update Dequeue pkt from A's retrans list 995 <--/LOST/-------------- 996 UPDATE (multicast) 997 Seq=101, Ack=0 998 Queues pkt on A's retrans list 1000 Retransmit Timer Expires 1001 <---------------- 1002 Retransmit UPDATE (unicast) 1003 Seq=101, Ack=0 1004 Keeps pkt on A's retrans list 1005 ----------------> 1006 ACK (unicast) 1007 Seq=0, Ack=101 Receives Ack 1008 Process Update Dequeue pkt from A's retrans list 1010 Figure 6 1011 Reliable Transfer on lossy point-to-point links 1013 Reliable delivery on multi-access LANs works in a similar fashion to 1014 point-to-point links. The initial packet is always multicast and 1015 subsequent retransmissions are unicast addressed. The acknowledgments 1016 sent are always unicast addressed. Figure 7 shows an example with 4 1017 routers on an Ethernet. 1019 Router B -----------+ 1020 | 1021 Router C -----------+------------ Router A 1022 | 1023 Router D -----------+ 1025 An UPDATE Exchange 1026 <---------------- 1027 A send UPDATE (multicast) 1028 Seq=100, Ack=0 1029 Queues pkt on B's retrans list 1030 Queues pkt on C's retrans list 1031 Queues pkt on D's retrans list 1032 ----------------> 1033 B sends ACK (unicast) 1034 Seq=0, Ack=100 Receives Ack 1035 Process Update Dequeue pkt from B's retrans list 1037 ----------------> 1038 C sends ACK (unicast) 1039 Seq=0, Ack=100 Receives Ack 1040 Process Update Dequeue pkt from C's retrans list 1042 ----------------> 1043 D sends ACK (unicast) 1044 Seq=0, Ack=100 Receives Ack 1045 Process Update Dequeue pkt from D's retrans list 1047 A QUERY Exchange 1048 <---------------- 1049 A send UPDATE (multicast) 1050 Seq=101, Ack=0 1051 Queues pkt on B's retrans list 1052 Queues pkt on C's retrans list 1053 Queues pkt on D's retrans list 1054 ----------------> 1055 B send REPLY (unicast) <---------------- 1056 Seq=511, Ack=101 A sends Ack (unicast to B) 1057 Process Update Seq=0, Ack=511 1058 Dequeue pkt from B's retrans list 1059 ----------------> 1060 C send REPLY (unicast) <---------------- 1061 Seq=200, Ack=101 A sends Ack (unicast to C) 1062 Process Update Seq=0, Ack=200 1063 Dequeue pkt from C's retrans list 1064 ----------------> 1065 D send REPLY (unicast) <---------------- 1066 Seq=11, Ack=101 A sends Ack (unicast to D) 1067 Process Update Seq=0, Ack=11 1068 Dequeue pkt from D's retrans list 1070 Figure 7 1071 Reliable Transfer on Multi-Access Links 1073 And finally, a situation where numerous multicast and unicast packets 1074 are sent close together in a multi-access environment is illustrated 1075 in Figure 9. 1077 Router B -----------+ 1078 | 1079 Router C -----------+------------ Router A 1080 | 1081 Router D -----------+ 1083 <---------------- 1084 A send UPDATE (multicast) 1085 Seq=100, Ack=0 1086 ---------------/LOST/-> Queues pkt on B's retrans list 1087 B send ACK (unicast) Queues pkt on C's retrans list 1088 Seq=0, Ack=100 Queues pkt on D's retrans list 1090 ----------------> 1091 C sends ACK (unicast) 1092 Seq=0, Ack=100 Dequeue pkt from C's retrans list 1094 ----------------> 1095 D sends ACK (unicast) 1096 Seq=0, Ack=100 Dequeue pkt from D's retrans list 1098 <---------------- 1099 A send HELLO (multicast) 1100 Seq=101, Ack=0, SEQ_TLV listing B 1102 B receives Hello, does not set CR-Mode 1103 C receives Hello, sets CR-Mode 1104 D receives Hello, sets CR-Mode 1105 <---------------- 1106 A send UPDATE (multicast) 1107 Seq=101, Ack=0, CR-Flag=1 1108 ---------------/LOST/-> Queues pkt on B's retrans list 1109 B send ACK (unicast) Queues pkt on C's retrans list 1110 Seq=0, Ack=100 Queues pkt on D's retrans list 1112 B ignores UPDATE 101 because CR-Flag 1113 is set and it is not in CR-Mode 1115 ----------------> 1116 C sends ACK (unicast) 1117 Seq=0, Ack=101 1119 ----------------> 1120 D sends ACK (unicast) 1121 Seq=0, Ack=101 1122 <---------------- 1123 A resends UPDATE (unicast to B) 1124 Seq=100, Ack=0 1125 B Packet duplicate 1126 ---------------> 1127 B sends ACK (unicast) A removes pkt from retrans list 1128 Seq=0, Ack=100 1129 <---------------- 1130 A resends UPDATE (unicast to B) 1131 Seq=101, Ack=0 1132 ---------------> 1133 B sends ACK (unicast) A removes pkt from retrans list 1134 Seq=0, Ack=101 1136 Figure 9 1138 Initially Router-A sends a multicast addressed UPDATE packet on the 1139 LAN. B and C receive it and send acknowledgments. Router-B receives 1140 the UPDATE but the acknowledgment sent is lost on the network. Before 1141 the retransmission timer for Router-B's packet expires, there is an 1142 event that causes a new multicast addressed UPDATE to be sent. 1144 Router-A detects that there is at least one neighbor on the interface 1145 with a full queue. Therefore, it is REQUIRED to tell that neighbor to 1146 not receive the next packet or it would receive it out of order. 1148 Router-A builds a HELLO packet with a SEQUENCE_TYPE TLV indicating 1149 all the neighbors that have full queues. In this case, the only 1150 neighbor address in the list is Router-B. The HELLO packet is 1151 multicasted unreliably out the interface. Router-C and Router-D 1152 process the SEQUENCE_TYPE TLV by looking for its own address in the 1153 list. If it is not found, they put themselves in Conditionally 1154 Received (CR-mode) mode. 1156 Any subsequent packets received that have the CR-flag set can be 1157 received. Router-B does not put itself in CR-mode because it finds 1158 itself in the list. Packets received by Router-B with the CR-flag 1159 MUST be discarded and not acknowledged. Later, Router-A will unicast 1160 transmit both packets 100 and 101 directly to Router-B. Router-B 1161 already has 100 so it discards and acknowledges it. 1163 Router-B then accepts packet 101 and acknowledges it too. Router-A 1164 can remove both packets off Router-B's transmission list. Next time 1165 when Router-A has an update to be sent to its neighbors, it sees that 1166 B is up to date w.r.t the updates it has to receive and it wouldn't 1167 get any Unicast packets (CR-Mode). 1169 5.2.1 Bandwidth on Low-Speed Links 1170 By default, EIGRP limits itself to using no more than 50% of the 1171 bandwidth reported by an interface when determining packet-pacing 1172 intervals. If the bandwidth does not match the physical bandwidth 1173 (the network architect may have put in an artificially low or high 1174 bandwidth value to influence routing decisions), EIGRP may: 1176 1. Generate more traffic than the interface can handle, possibly 1177 causing drops, thereby impairing EIGRP performance. 1179 2. Generate a lot of EIGRP traffic that could result in little 1180 bandwidth remaining for user data. To control such transmissions an 1181 interface-pacing timer is defined for the interfaces on which EIGRP 1182 is enabled. When a pacing timer expires, a packet is transmitted out 1183 on that interface. 1185 5.3 Neighbor Discovery/Recovery 1186 Neighbor Discovery/Recovery is the process that routers use to 1187 dynamically learn of other routers on their directly attached 1188 networks. Routers MUST also discover when their neighbors become 1189 unreachable or inoperative. This process is achieved with low 1190 overhead by periodically sending small HELLO packets. As long as any 1191 packets are received from a neighbor, the router can determine that 1192 neighbor is alive and functioning. Only after a neighbor router is 1193 considered operational can the neighboring routers exchange routing 1194 information. 1196 5.3.1 Neighbor HoldTime 1197 Each router keeps state information about adjacent neighbors. When 1198 newly discovered neighbors are learned the address, interface, and 1199 hold time of the neighbor is noted. When a neighbor sends a HELLO, 1200 it advertises its HoldTime. The HoldTime is the amount of time a 1201 router treats a neighbor as reachable and operational. In other 1202 words, if a HELLO packet isn't heard within the HoldTime, then the 1203 HoldTime expires. When the HoldTime expires, DUAL is informed of the 1204 topology change. 1206 5.3.2 HELLO Packets 1207 When an EIGRP router is initialized, it will start sending HELLO 1208 packets out any interface for which EIGRP is enabled. HELLO packets, 1209 when used for neighbor discovery, are normally sent multicast 1210 addressed. The HELLO packet will include the configured EIGRP metric 1211 K-values. Two routers become neighbors only if the K-values are the 1212 same. This enforces that the metric usage is consistent throughout 1213 the Internet. Also included in the HELLO packet, is a HoldTime value. 1214 This value indicates to all receivers the length of time in seconds 1215 that the neighbor is valid. The default HoldTime will be 3 times the 1216 HELLO interval. HELLO packets will be transmitted every 5 seconds (by 1217 default). There MAY be a configuration command that controls this 1218 value and therefore changes the HoldTime. HELLO packets are not 1219 transmitted reliably so the sequence number should be set to 0. 1221 5.3.3 UPDATE Packets 1222 When a router detects a new neighbor by receiving a HELLO packet from 1223 a neighbor not presently known, it will send a unicast UPDATE packet 1224 to the neighbor with no routing information. The initial UPDATE sent 1225 MUST have the INIT-flag set. This instructs the neighbor to advertise 1226 its routes. The INIT-flag is also useful when a neighbor goes down 1227 and comes back up before the router detects it went down. In this 1228 case, the neighbor needs new routing information. The INIT-flag 1229 informs the router to send it. 1231 5.3.4 Initialization Sequence 1232 Router A Router B 1233 (just booted) (up and running) 1235 (1)----------------> 1236 <---------------- (2) 1237 HELLO (multicast) 1238 Seq=0, Ack=0 1240 HELLO (multicast) <---------------- (3) 1241 Seq=0, Ack=0 UPDATE (unicast) 1242 Seq=10, Ack=0, INIT 1243 (4)----------------> UPDATE 11 us queued 1244 UPDATE (unicast) 1245 Seq=100, Ack=10, INIT <---------------- (5) 1246 UPDATE (unicast) 1247 Seq=11, Ack=100 1248 All UPDATES sent 1249 (6)--------------/lost/-> 1250 ACK (unicast) 1251 Seq=0, Ack=11 1252 (5 seconds later) 1253 <---------------- (7) 1254 Duplicate received, UPDATE (unicast) 1255 Packet discarded Seq=11, Ack=100 1256 (8)---------------> 1257 ACK (unicast) 1258 Seq=0, Ack=11 1260 Figure 9 - Initialization Sequence 1262 (1) Router A sends multicast HELLO and Router B discovers it. 1264 (2) Router B sends an expedited HELLO and starts the process of 1265 sending its topology table to Router A. The number of destinations in 1266 its routing table will require at least 2 UPDATE packets to be sent. 1267 The first UPDATE (referred it as the NULL UPDATE) is sent with the 1268 INIT-Flag, and congaing no topology information. The second packet is 1269 queued, and cannot be sent until the first is acknowledged. 1271 (3) Router A receives first UPDATE and processes it as a DUAL event. 1272 If the UPDATE contains topology information, the packet will be 1273 process and stored in topology table. Sends its first and only UPDATE 1274 packet with an accompanied Ack. 1276 (4) Router B receives UPDATE packet 100 from Router A. Router B can 1277 dequeue packet 10 from A's transmission list since the UPDATE 1278 acknowledged 10. It can now send UPDATE packet 11 and with an 1279 acknowledgment of Router A's UPDATE. 1281 (5) Router A receives the last UPDATE from Router B and acknowledges 1282 it. The acknowledgment gets lost. 1284 (6) Router B later retransmits the UPDATE to Router A. 1286 (7) Router A detects the duplicate and simply acknowledges the 1287 packet. Router B dequeues packet 11 from A's transmission list and 1288 both routers are up and synchronized. 1290 5.3.5 QUERY Packets During Neighbor Formation 1291 As described above, during the initial formation of the neighbor 1292 relationship, EIGRP uses a form of three-way handshake to verify both 1293 unicast and multicast connectivity are working successfully. During 1294 this period of neighbor creation the new neighbor is considered to be 1295 the pending state, and is not eligible to be included in the 1296 convergence process. Because of this, any QUERY received by an EIGRP 1297 router would not cause a QUERY to be sent to the new (and pending) 1298 neighbor. It would perform the DUAL process without the new peer in 1299 the conversation. 1300 To do this, when a router in the process of establishing a new 1301 neighbor receives a QUERY from a fully established neighbor, it 1302 performs the normal DUAL Feasible Successor check to determine 1303 whether it needs to REPLY with a valid path or whether it needs to 1304 enter the Active process on the prefix. 1305 If it determines that it must go active, each fully established 1306 neighbor that participates in the convergence process will be sent a 1307 QUERY packet and REPLY packets are expected from each. Any pending 1308 neighbor will not be expected to REPLY and will not be sent a QUERY 1309 directly. If it resides on an interface containing a mix of fully 1310 established neighbors and pending neighbors, it might receive the 1311 QUERY but will not be expected to REPLY to it. 1313 5.3.6 Neighbor Formation 1314 To prevent packets from being sent to a neighbor prior to the 1315 multicast and unicast delivery has been verified as reliable, a 3-way 1316 handshake is utilized. 1318 During normal adjacency formation, multicast HELLOs cause the EIGRP 1319 process to place new neighbors into the neighbor table. Unicast 1320 packets are then used to exchange known routing information, and 1321 complete the neighbor relationship (section 5.2) 1323 To prevent EIGRP from sending sequenced packets to neighbor which 1324 fail to have bidirectional unicast/multicast, or one neighbor 1325 restarts while building the relationship, EIGRP SHALL place the newly 1326 discovered neighbor in a "pending" state as follows: 1327 When Router-A receives the first multicast HELLO from Router-B, it 1328 places Router-B in the pending state, and transmits a unicast UPDATE 1329 containing no topology information and SHALL set the initialization 1330 bit 1331 While Router-B is in this state, A will not send it any a QUERY or 1332 UPDATE 1333 When Router-A receives the unicast acknowledgement from Router-B, it 1334 will check the state from pending to up 1336 5.3.7 Topology Table 1337 The Topology Table is populated by the protocol dependent modules and 1338 acted upon by the DUAL finite state machine. It contains all 1339 destinations advertised by neighboring routers. Associated with each 1340 entry are the destination address and a list of neighbors that have 1341 advertised this destination. For each neighbor, the advertised metric 1342 is recorded. This is the metric that the neighbor stores in its 1343 routing table. If the neighbor is advertising this destination, it 1344 must be using the route to forward packets. This is an important rule 1345 that distance vector protocols MUST follow. 1346 Also associated with the destination is the metric that the router 1347 uses to reach the destination. This is the sum of the best-advertised 1348 metric from all neighbors plus the link cost to the best neighbor. 1349 This is the metric that the router uses in the routing table and to 1350 advertise to other routers. 1352 5.3.8 Route Management 1353 EIGRP has the notion of internal and external routes. Internal routes 1354 are ones that have been originated within an EIGRP Autonomous 1355 System(AS). Therefore, a directly attached network that is configured 1356 to run EIGRP is considered an internal route and is propagated with 1357 this information throughout the network topology. 1358 External routes are destinations that have been learned though 1359 another source, such as a routing protocol or static route. These 1360 routes are marked individually with the identity of their 1361 origination. 1363 External routes are tagged with the following information: 1364 o The router ID of the EIGRP router that redistributed the route. 1365 o The AS number where the destination resides. 1366 o A configurable administrator tag. 1367 o Protocol ID of the external protocol. 1368 o The metric from the external protocol. 1369 o Bit flags for default routing. 1371 As an example, suppose there is an AS with three border routers (BR1, 1372 BR2, and BR3). A border router is one that runs more than one routing 1373 protocol. The AS uses EIGRP as the routing protocol. Two of the 1374 border routers, BR1 and BR2, also use Open Shortest Path First (OSPF) 1375 and the other, BR3, also uses Routing Information Protocol (RIP). 1377 Routes learned by one of the OSPF border routers, BR1, can be 1378 conditionally redistributed into EIGRP. This means that EIGRP running 1379 in BR1 advertises the OSPF routes within its own AS. When it does so, 1380 it advertises the route and tags it as an OSPF learned route with a 1381 metric equal to the routing table metric of the OSPF route. The 1382 router-id is set to BR1. The EIGRP route propagates to the other 1383 border routers. 1385 Let's say that BR3, the RIP border router, also advertises the same 1386 destinations as BR1. Therefore BR3, redistributes the RIP routes into 1387 the EIGRP AS. BR2, then, has enough information to determine the AS 1388 entry point for the route, the original routing protocol used, and 1389 the metric. 1391 Further, the network administrator could assign tag values to 1392 specific destinations when redistributing the route. BR2 can use any 1393 of this information to use the route or re-advertise it back out into 1394 OSPF. 1396 Using EIGRP route tagging can give a network administrator flexible 1397 policy controls and help customize routing. Route tagging is 1398 particularly useful in transit AS's where EIGRP would typically 1399 interact with an inter-domain routing protocol that implements more 1400 global policies. 1402 5.4 EIGRP Metric Coefficients 1403 EIGRP allows for modification of the default composite metric 1404 calculation through the use of coefficients (K-values). This 1405 adjustment allows for per-deployment tuning of network behavior. 1406 Setting K-values up to 254 scales the impact of the scalar metric on 1407 the final composite metric. 1409 EIGRP default coefficients have been carefully selected to provide 1410 optimal performance in most networks. The default K-values are 1412 K1 == K3 == 1 1413 K2 == K4 == K5 == 0 1414 K6 == 0 1416 If K5 is equal to 0 then reliability quotient is defined to be 1. 1418 5.4.1 Coefficients K1 and K2 1419 K1 is used to allow path selection to be based on the bandwidth 1420 available along the path. EIGRP can use one of two variations of 1421 Throughput based path selection. 1422 o Maximum Theoretical Bandwidth; paths chosen based on the highest 1423 reported bandwidth 1424 o Network Throughput: paths chosen based on the highest 'available' 1425 bandwidth adjusted by congestion-based effects (interface reported 1426 load) 1428 By default EIGRP computes the Throughput using the maximum 1429 theoretical throughput expressed in picoseconds per kilobyte of data 1430 sent. This inversion results in a larger number (more time) 1431 ultimately generating a worse metric. 1433 If K2 is used, the effect of congestion as a measure of load reported 1434 by the interface will be used to simulate the "available throughput 1435 by adjusting the maximum throughput. 1437 5.4.2 Coefficients K3 1438 K3 is used to allow delay or latency-based path selection. Latency 1439 and Delay are similar terms that refer to the amount of time it takes 1440 a bit to be transmitted to an adjacent neighbor. EIGRP uses one-way 1441 based values either provided by the interface, or computed as a 1442 factor of the links bandwidth. 1444 5.4.3 Coefficients K4 and K5 1445 K4 and K5 are used to allow for path selection based on link quality 1446 and packet loss. Packet loss caused by network problems result in 1447 highly noticeable performance issues or jitter with streaming 1448 technologies, voice over IP, online gaming and videoconferencing, and 1449 will affect all other network applications to one degree or another. 1451 Critical services should pass with less than 1% packet loss. Lower 1452 priority packet types might pass with less than 5% and then 10% for 1453 the lowest of priority of services. The final metric can be weighted 1454 based on the reported link quality. 1456 The handling of K5 is conditional. If K5 is equal to 0 then 1457 reliability quotient is defined to be 1. 1459 5.4.4 Coefficients K6 1460 K6 has been introduced with Wide Metric support and is used to allow 1461 for Extended Attributes, which can be used to reflect in a higher 1462 aggregate metric than those having lower energy usage. 1463 Currently there are two Extended Attributes, jitter and energy, 1464 defined in the scope of this document. 1466 5.4.4.1 Jitter 1467 Use of Jitter-based Path Selection results in a path calculation with 1468 the lowest reported jitter. Jitter is reported as the interval 1469 between the longest and shortest packet delivery and is expressed in 1470 microseconds. Higher values results in a higher aggregate metric when 1471 compared to those having lower jitter calculations. 1473 Jitter is measured in microseconds and is accumulated along the path, 1474 with each hop using an averaged 3-second period to smooth out the 1475 metric change rate. 1477 Presently, EIGRP does not currently have the ability to measure 1478 jitter, and as such the default value will be zero (0). Performance 1479 based solutions such as PfR could be used to populate this field. 1481 5.4.4.2 Energy 1482 Use of Energy-based Path Selection results in paths with the lowest 1483 energy usage being selected in a loop free and deterministic manner. 1484 The amount of energy used is accumulative and has results in a higher 1485 aggregate metric than those having lower energy. 1487 Presently, EIGRP does not report energy usage, and as such the 1488 default value will be zero (0). 1490 5.5 5.5 EIGRP Metric Calculations 1491 5.5.1 Classic Metrics 1492 One of the original goals of EIGRP was to offer and enhance routing 1493 solutions for IGRP. To achieve this, EIGRP used the same composite 1494 metric as IGRP, with the terms multiplied by 256 to change the metric 1495 from 24 bits to 32 bits. 1497 The composite metric is based on bandwidth, delay, load, and 1498 reliability. MTU is not an attribute for calculating the composite 1499 metric. 1501 5.5.1.1 Classic Composite Formulation 1502 EIGRP calculates the composite metric with the following formula: 1504 metric = {K1*BW+[(K2*BW)/(256-load)]+(K3*delay)}*{K5/(REL+K4)} 1506 In this formula, Bandwidth (BW) is the lowest interface bandwidth 1507 along the path, and delay is the sum of all outbound interface delays 1508 along the path. The router dynamically measures reliability (REL) and 1509 load. It expresses 100 percent reliability as 255/255. It expresses 1510 load as a fraction of 255. An interface with no load is represented 1511 as 1/255. 1513 Bandwidth is the inverse minimum bandwidth (in kbps) of the path in 1514 bits per second scaled by a factor of 256 multiplied by 10^7. The 1515 formula for bandwidth is 1517 (256 x (10 ^ 7))/BWmin 1519 The delay is the sum of the outgoing interface delay (in 1520 microseconds) to the destination. A delay set to it maximum value 1521 (hexadecimal FFFFFFFF) indicates that the network is unreachable. The 1522 formula for delay is 1524 [sum of delays] x 256 1526 Reliability is a value between 1 and 255. Cisco IOS routers display 1527 reliability as a fraction of 255. That is, 255/255 is 100 percent 1528 reliability or a perfectly stable link; a value of 229/255 represents 1529 a 90 percent reliable link. Load is a value between 1 and 255. A 1530 load of 255/255 indicates a completely saturated link. A load of 1531 127/255 represents a 50 percent saturated link. 1533 The default composite metric, adjusted for scaling factors, for EIGRP 1534 is: 1535 metric = 256 x { [(10^7)/ BWmin] + [sum of delays]} 1537 Minimum Bandwidth (BWmin) is represented in kbps, and the "sum of 1538 delays" is represented in 10s of microseconds. The bandwidth and 1539 delay for an Ethernet interface are 10Mbps and 1ms, respectively. 1541 The calculated EIGRP BW metric is then: 1543 256 x (10^7)/BW = 256 x {(10^7)/10,000} 1544 = 256 x 10,000 1545 = 256,00 1547 And the calculated EIGRP delay metric is then: 1549 256 x sum of delay = 256 x 1 ms 1550 = 256 x 100 x 10 microseconds 1551 = 25,600 (in tens of microseconds) 1553 5.5.1.2 Cisco Interface Delay Compatibility 1554 For compatibility with Cisco products, the following table shows the 1555 times in picoseconds EIGRP uses for bandwidth and delay 1556 Bandwidth Classic Wide Metrics Interface 1557 (Kbps) Delay Delay Type 1558 --------------------------------------------------------- 1559 9 500000000 500000000 Tunnel 1560 56 20000000 20000000 56Kb/s 1561 64 20000000 20000000 DS0 1562 1544 20000000 20000000 T1 1563 2048 20000000 20000000 E1 1564 10000 1000000 1000000 Ethernet 1565 16000 630000 630000 TokRing16 1566 45045 20000000 20000000 HSSI 1567 100000 100000 100000 FDDI 1568 100000 100000 100000 FastEthernet 1569 155000 100000 100000 ATM 155Mb/s 1570 1000000 10000 10000 GigaEthernet 1571 2000000 10000 5000 2 Gig 1572 5000000 10000 2000 5 Gig 1573 10000000 10000 1000 10 Gig 1574 20000000 10000 500 20 Gig 1575 50000000 10000 200 50 Gig 1576 100000000 10000 100 100 Gig 1577 200000000 10000 50 200 Gig 1578 500000000 10000 20 500 Gig 1580 5.5.2 Wide Metrics 1581 To accommodate interfaces with high bandwidths, and to allow EIGRP to 1582 perform the path selection; the EIGRP packet and composite metric 1583 formula has been modified to choose paths based on the computed time, 1584 measured in picoseconds, information takes to travel though the 1585 links. 1587 5.5.2.1 Wide Metric Vectors 1588 EIGRP uses five 'vector' metrics: minimum throughput, latency, load, 1589 reliability, and maximum transmission unit (MTU). These values are 1590 calculated from destination to source as follows: 1591 o Throughput - Minimum value 1592 o Latency - accumulative 1593 o Load - maximum 1594 o Reliability - minimum 1595 o MTU - minimum 1596 o Hop count - Accumulative 1598 To this there are two additional values: jitter and energy. These two 1599 values are accumulated from destination to source: 1600 o Jitter - accumulative 1601 o Energy - accumulative 1603 These Extended Attributes, as well as any future ones, will be 1604 controlled via K6. If K6 is non-zero, these will be additive to the 1605 path's composite metric. Higher jitter or energy usage will result 1606 in paths that are worse than those which either does not monitor 1607 these attributes, or which have lower values. 1609 EIGRP will not send these attributes if the router does not provide 1610 them. If the attributes are received, then EIGRP will use them in 1611 the metric calculation (based on K6) and will forward them with those 1612 routers values assumed to be "zero" and the accumulative values are 1613 forwarded unchanged. 1615 The use of the vector metrics allows EIGRP to compute paths based on 1616 any of four (bandwidth, delay, reliability, and load) path selection 1617 schemes. The schemes are distinguished based on the choice of the key 1618 measured network performance metric. 1620 Of these vector metric components, by default, only minimum 1621 throughput and latency are traditionally used to compute best path. 1622 Unlike most metrics, minimum throughput is set to the minimum value 1623 of the entire path, and it does not reflect how many hops or low 1624 throughput links are in the path, nor does it reflect the 1625 availability of parallel links. Latency is calculated based on one- 1626 way delays, and is a cumulative value, which increases with each 1627 segment in the path. 1629 Network Designers Note: when trying to manually influence EIGRP path 1630 selection though interface bandwidth/delay configuration, the 1631 modification of bandwidth is discouraged for following reasons: 1633 The change will only effect the path selection if the configured 1634 value is the lowest bandwidth over the entire path. 1635 Changing the bandwidth can have impact beyond affecting the EIGRP 1636 metrics. For example, quality of service (QoS) also looks at the 1637 bandwidth on an interface. 1639 EIGRP throttles to use 50 percent of the configured bandwidth. 1640 Lowering the bandwidth can cause problems like starving EIGRP 1641 neighbors from getting packets because of the throttling back. 1643 Changing the delay does not impact other protocols nor does it cause 1644 EIGRP to throttle back, and because, as it's the sum of all delays, 1645 has a direct effect on path selection. 1647 5.5.2.2 Wide Metric Conversion Constants 1648 EIGRP uses a number of defined constants for conversion and 1649 calculation of metric values. These numbers are provided here for 1650 reference 1652 EIGRP_BANDWIDTH 10,000,000 1653 EIGRP_DELAY_PICO 1,000,000 1654 EIGRP_INACCESSIBLE 0xFFFFFFFFFFFFFFFFLL 1655 EIGRP_MAX_HOPS 100 1656 EIGRP_CLASSIC_SCALE 256 1657 EIGRP_WIDE_SCALE 65536 1658 EIGRP_RIB_SCALE 128 1660 When computing the metric using the above units, all capacity 1661 information will be normalized to kilobytes and picoseconds before 1662 being used. For example, delay is expressed in microseconds per 1663 kilobyte, and would be converted to kilobytes per second; likewise 1664 energy would be expressed in power per kilobytes per second of usage. 1666 5.5.2.3 Throughput Formulation 1667 The formula for the conversion for Max-Throughput value directly from 1668 the interface without consideration of congestion-based effects is as 1669 follows: 1671 (EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE) 1672 Max-Throughput = K1 * ------------------------------------ 1673 Interface Bandwidth (kbps) 1675 If K2 is used, the effect of congestion as a measure of load reported 1676 by the interface will be used to simulate the "available throughput 1677 by adjusting the maximum throughput according to the formula: 1679 K2 * Max-Throughput 1680 Net-Throughput = Max-Throughput + --------------------- 1681 256 - Load 1683 K2 has the greatest effect on the metric occurs when the load 1684 increases beyond 90%. 1686 5.5.2.4 Latency Formulation 1687 Transmission times derived from physical interfaces MUST be n units 1688 of picoseconds, or converted to picoseconds prior to being exchanged 1689 between neighbors, or used in the composite metric determination. 1691 This includes delay values present in configuration-based commands 1692 (i.e. interface delay, redistribute, default-metric, route-map, etc.) 1694 The delay value is then converted to a "latency" using the formula: 1696 Delay * EIGRP_WIDE_SCALE 1697 Latency = K3 * -------------------------- 1698 EIGRP_DELAY_PICO 1700 5.5.2.5 Composite Formulation 1701 K5 1702 metric =[(K1*Net-Throughput) + Latency)+(K6*ExtAttr)] * ------ 1703 K4+Rel 1705 By default, the path selection scheme used by EIGRP is a combination 1706 of Throughput and Latency where the selection is a product of total 1707 latency and minimum throughput of all links along the path: 1709 metric = (K1 * min(Throughput)) + (K3 * sum(Latency)) } 1711 6 Security Considerations 1712 By the nature of being promiscuous, EIGRP will neighbor with any 1713 router that sends a valid HELLO packet. Due to security 1714 considerations, this "completely" open aspect requires policy 1715 capabilities to limit peering to valid routers. 1717 EIGRP does not rely on a PKI or a more heavy weight authentication 1718 system. These systems challenge the scalability of EIGRP, which was a 1719 primary design goal. 1721 Instead, DoS attack prevention will depend on implementations rate- 1722 limiting packets to the control plane as well as authentication of 1723 the neighbor though the use of SHA2-256 1725 7 IANA Considerations 1726 This document has no actions for IANA. 1728 8 References 1730 8.1 Normative References 1731 [1] Bradner, S., "Key words for use in RFCs to Indicate 1732 Requirement Levels", BCP 14, [RFC2119], April 1997. 1733 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 1734 Syntax Specifications: ABNF", [RFC2234], Internet Mail Consortium and 1735 Demon Internet Ltd., November 1997. 1736 [3] A Unified Approach to Loop-Free Routing using Distance Vectors 1737 or Link States, J.J. Garcia-Luna-Aceves, 1989 ACM 089791-332- 1738 9/89/0009/0212, pages 212-223. 1739 [4] Loop-Free Routing using Diffusing Computations, J.J. Garcia- 1740 Luna-Aceves, Network Information Systems Center, SRI International to 1741 appear in IEEE/ACM Transactions on Networking, Vol. 1, No. 1, 1993. 1742 [5] BGP Extended Communities Attribute [RFC4360] 1743 [6] HMAC-SHA256, SHA384, SHA512 in IPsec [RFC4868] 1745 8.2 Informative References 1746 [7] OSPF Version 2, Network Working Group [RFC1247], J. Moy, July 1747 1991. 1749 [8] Guidelines for Considering New Performance Metric Development 1750 [RFC6390] 1751 9 Acknowledgments 1752 This document was prepared using 2-Word-v2.0.template.dot. 1754 An initial thank you goes to Dino Farinacci, Bob Albrightson, and 1755 Dave Katz. Their significant accomplishments towards the design and 1756 development of the EIGRP protocol provided the bases for this 1757 document. 1759 A special and appreciative thank you goes to the core group of Cisco 1760 engineers, whose dedication, long hours, and hard work lead the 1761 evolution of EIGRP over the following decade. They are Donnie 1762 Savage, Mickel Ravizza, Heidi Ou, Dawn Li, Thuan Tran, Catherine 1763 Tran, Don Slice, Claude Cartee, Donald Sharp, Steven Moore, Richard 1764 Wellum, Ray Romney, Jim Mollmann, Dennis Wind, Chris Van Heuveln, 1765 Gerald Redwine, Glen Matthews, Michael Wiebe, and others. 1767 The authors would like to gratefully acknowledge many people who have 1768 contributed to the discussions that lead to the making of this 1769 proposal. They include Chris Le, Saul Adler, Scott Van de Houten, 1770 Lalit Kumar, Yi Yang, Kumar Reddy, David Lapier, Scott Kirby, David 1771 Prall, Jason Frazier, Eric Voit, Dana Blair, Jim Guichard, and Alvaro 1772 Retana. 1774 A EIGRP Packet Formats 1776 A.1 Protocol Number 1777 The IPv6 and IPv4 protocol identifier number spaces are common and 1778 will both use protocol identifier 88. 1780 EIGRP IPv6 will transmit HELLO packets with a source address being 1781 the link-local address of the transmitting interface. Multicast HELLO 1782 packets will have a destination address of FF02::A (the EIGRP IPv6 1783 multicast address). Unicast packets directed to a specific neighbor 1784 will contain the destination link-local address of the neighbor. 1786 There is no requirement that two EIGRP IPv6 neighbors share a common 1787 prefix on their connecting interface. EIGRP IPv6 will check that a 1788 received HELLO contains a valid IPv6 link-local source address. Other 1789 HELLO processing will follow common EIGRP checks, including matching 1790 Autonomous system number and matching K-values. 1792 A.2 Protocol Assignment Encoding 1793 External Protocol Field is an informational assignment to identify 1794 the originating routing protocol that this route was learned by. The 1795 following values are assigned: 1797 Protocols Value 1798 IGRP 1 1799 EIGRP 2 1800 Static 3 1801 RIP 4 1802 HELLO 5 1803 OSPF 6 1804 ISIS 7 1805 EGP 8 1806 BGP 9 1807 IDRP 10 1808 Connected 11 1810 A.3 Destination Assignment Encoding 1811 Destinations types are encoded according to the IANA address family 1812 number assignments. Currently on the following types are used: 1814 AFI Designation AFI Value 1815 -------------------------------------- 1816 IPv4 Address 1 1817 IPv6 Address 2 1818 Service Family Common 16384 1819 Service Family IPv4 16385 1820 Service Family IPv6 16386 1822 A.4 EIGRP Communities Attribute 1823 EIGRP supports communities similar to the BGP Extended Communities 1824 [5] extended type with Type Field composed of 2 octets and Value 1825 Field composed of 6 octets. Each Community is encoded as an 8-octet 1826 quantity, as follows: 1827 - Type Field: 1 or 2 octets 1828 - Value Field: Remaining octets 1830 0 1 2 3 1831 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 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | Type high | Type low | | 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | 1835 | | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1838 In addition to well-known communities supported by BGP (such as Site 1839 of Origin), EIGRP defines a number of additional defined Community 1840 values as follows: 1841 Value Name Description 1842 --------------------------------------------------------------- 1843 8800 EXTCOMM_EIGRP EIGRP route information appended 1844 8801 EXTCOMM_DAD Data: AS + Delay 1845 8802 EXTCOMM_VRHB Vector: Reliability + Hop + BW 1846 8803 EXTCOMM_SRLM System: Reserve +Load + MTU 1847 8804 EXTCOMM_SAR System: Remote AS + Remote ID 1848 8805 EXTCOMM_RPM Remote: Protocol + Metric 1849 8806 EXTCOMM_VRR Vecmet: Rsvd + RouterID 1851 A.5 EIGRP Packet Header 1852 The basic EIGRP packet payload format is identical for all three 1853 protocols, although there are some protocol-specific variations. 1854 Packets consist of a header, followed by a set of variable-length 1855 fields consisting of Type/Length/Value (TLV) triplets. 1857 0 1 2 3 1858 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 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 |Header Version | Opcode | Checksum | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | Flags | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 | Sequence Number | 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 | Acknowledgement number | 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 | Virtual Router ID | Autonomous system number | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 Header Version - EIGRP Packet Header Format version. Current Version 1872 is 2. This field is not the same as the TLV Version field. 1873 Opcode - EIGRP opcode indicating function packet serves. It will be 1874 one of the following values: 1876 EIGRP_OPC_UPDATE 1 1877 EIGRP_OPC_REQUEST 2 1878 EIGRP_OPC_QUERY 4 1879 EIGRP_OPC_REPLY 4 1880 EIGRP_OPC_HELLO 5 1881 Reserved 6 1882 EIGRP_OPC_PROBE 7 1883 Reserved 8 1884 Reserved 9 1885 EIGRP_OPC_SIAQUERY 10 1886 EIGRP_OPC_SIAREPLY 11 1888 Checksum - Each packet will include a checksum for the entire 1889 contents of the packet. The check-sum will be the standard ones 1890 complement of the ones complement sum. The packet is discarded if the 1891 packet checksum fails. 1893 Flags - Defines special handling of the packet. There are currently 1894 two defined flag bits. 1896 Init Flag (0x01) - This bit is set in the initial UPDATE packet sent 1897 to a newly discovered neighbor. It requests the neighbor to download 1898 a full set of routes. 1900 CR Flag (0x02) - This bit indicates that receivers should only accept 1901 the packet if they are in Conditionally Received mode. A router 1902 enters conditionally received mode when it receives and processes a 1903 HELLO packet with a Sequence TLV present. 1905 RS (0x04) - The Restart flag is set in the HELLO and the init UPDATE 1906 packets during the signaling period. Thee router looks at the RS flag 1907 to detect if a neighbor is restarting and maintain the adjacency. A 1908 restarting router looks at this flag to determine if the neighbor is 1909 helping out with the restart. 1911 EOT (0x08) - The End-of-Table flag marks the end of the startup 1912 process with a new neighbor. A restarting router looks at this flag 1913 to determine if it has finished receiving the startup UPDATE packets 1914 from all neighbors, before cleaning up the stale routes from the 1915 restarting neighbor. 1917 Sequence - Each packet that is transmitted will have a 32-bit 1918 sequence number that is unique respect to a sending router. A value 1919 of 0 means that an acknowledgment is not required. 1921 Ack - The 32-bit sequence number that is being acknowledged with 1922 respect to receiver of the packet. If the value is 0, there is no 1923 acknowledgment present. A non-zero value can only be present in 1924 unicast-addressed packets. A HELLO packet with a nonzero ACK field 1925 should be decoded as an ACK packet rather than a HELLO packet. 1927 Virtual Router ID (VRID) - A 16-bit number, which identifies the 1928 virtual router, this packet is associated. Packets received with an 1929 unknown, or unsupported VRID will be discarded. 1931 Value Range Usage 1932 0000 Unicast Address Family 1933 0001 Multicast Address Family 1934 0002-7FFFF Reserved 1935 8000 Unicast Service Family 1936 8001-FFFF Reserved 1938 Autonomous System (AS) - 16 bit unsigned number of the sending 1939 system. This field is indirectly used as an authentication value. 1940 That is, a router that receives and accepts a packet from a neighbor 1941 must have the same AS number or the packet is ignored. 1943 A.6 EIGRP TLV Encoding Format 1944 The contents of each packet can contain a variable number of fields. 1945 Each field will be tagged and include a length field. This allows for 1946 newer versions of software to add capabilities and coexist with old 1947 versions of software in the same configuration. Fields that are 1948 tagged and not recognized can be skipped over. Another advantage of 1949 this encoding scheme allows multiple network layer protocols to carry 1950 independent information. Therefore, later if it is decided to 1951 implement a single "integrated" protocol this can be done. 1953 The format of a {type, length, value} (TLV) is encoded as follows: 1955 0 1 2 3 1956 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 1957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1958 | Type high | Type low | Length | 1959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1960 | Value (variable length) | 1961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 The type values are the ones defined below. The length value 1963 specifies the length in octets of the type, length and value fields. 1964 TLVs can appear in a packet in any order and there are no inter- 1965 dependencies among them. 1967 A.6.1 Type Field Encoding 1968 The type field is structured as follows: 1969 Type High: 1 octet that defines the protocol classification: 1970 Protocol ID VERSION 1971 General 0x00 1.2 1972 IPv4 0x01 1.2 1973 IPv6 0x04 1.2 1974 SAF 0x05 3.0 1975 Multi-Protocol 0x06 2.0 1977 Type Low: 1 octet that defines the TLV Opcode 1978 See TLV Definitions in Section 3 1980 A.6.2 Length Field Encoding 1981 The Length field is a 2 octet unsigned number, which indicates the 1982 length of the TLV. The value does includes the Type and Length 1983 fields 1985 A.6.3 Value Field Encoding 1986 The Value field is a multi-octet field containing the payload for the 1987 TLV. 1989 A.7 EIGRP Generic TLV Definitions 1990 Ver 1.2 Ver 2.0 1991 PARAMETER_TYPE 0x0001 0x0001 1992 AUTHENTICATION_TYPE 0x0002 0x0002 1993 SEQUENCE_TYPE 0x0003 0x0003 1994 SOFTWARE_VERSION_TYPE 0x0004 0x0004 1995 MULTICAST_SEQUENCE _TYPE 0x0005 0x0005 1996 PEER_INFORMATION _TYPE 0x0006 0x0006 1997 PEER_TERMINATION_TYPE 0x0007 0x0007 1998 PEER_TID_LIST_TYPE --- 0x0008 2000 A.7.1 0x0001 - PARAMETER_TYPE 2001 This TLV is used in HELLO packets to convey the EIGRP metric 2002 coefficient values - noted as "K-values" as well as the Holdtime 2003 values. This TLV is also used in an initial UPDATE packet when a 2004 neighbor is discovered. 2006 0 1 2 3 2007 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 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 | 0x0001 | 0x000C | 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 | K1 | K2 | K3 | K4 | 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 | K5 | K6 | Hold Time | 2014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 K-values - The K-values associated with the EIGRP composite metric 2017 equation. The default values for weights are: 2018 K1 - 1 2019 K2 - 0 2020 K3 - 1 2021 K4 - 0 2022 K5 - 0 2023 K6 - 0 2025 Hold Time - The amount of time in seconds that a receiving router 2026 should consider the sending neighbor valid. A valid neighbor is one 2027 that is able to forward packets and participates in EIGRP. A router 2028 that considers a neighbor valid will store all routing information 2029 advertised by the neighbor. 2031 A.7.2 0x0002 - AUTHENTICATION_TYPE 2032 This TLV may be used in any EIGRP packet and conveys the 2033 authentication type and data used. Routers receiving a mismatch in 2034 authentication shall discard the packet. 2036 0 1 2 3 2037 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 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 | 0x0002 | Length | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 | Auth Type | Auth Length | Auth Data (Variable) | 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2044 Authentication Type - The type of authentication used. 2045 Authentication Length - The length, measured in octets, of the 2046 individual authentication. 2047 Authentication Data - Variable length field reflected by "Auth 2048 Length" which is dependent on the type of authentication used. 2049 Multiple authentication types can be present in a single 2050 AUTHENTICATION_TYPE TLV. 2052 A.7.2.1 0x02 - MD5 Authentication Type 2053 MD5 Authentication will use Auth Type code 0x02, and the Auth Data 2054 will be the MD5 Hash value. 2056 A.7.2.2 0x03 - SHA2 Authentication Type 2057 SHA2-256 Authentication will use Type code 0x03, and the Auth Data 2058 will be the 256 bit SHA2[6] Hash value 2060 A.7.3 0x0003 - SEQUENCE_TYPE 2061 This TLV is used for a sender to tell receivers to not accept packets 2062 with the CR-flag set. This is used to order multicast and unicast 2063 addressed packets. 2065 0 1 2 3 2066 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 2067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2068 | 0x0003 | Length | 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 |Address Length | Protocol Address | 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 The Address Length and Protocol Address will be repeated one or more 2074 times based on the Length Field. 2076 Address Length - Number of octets for the address that follows. For 2077 IPv4, the value is 4. For AppleTalk, the value is 4. For Novell IPX, 2078 the value is 10, for IPv6 it is 16 2080 Protocol Address - Neighbor address on interface in which the HELLO 2081 with SEQUENCE TLV is sent. Each address listed in the HELLO packet is 2082 a neighbor that should not enter Conditionally Received mode. 2084 A.7.4 0x0004 - SOFTWARE_VERSION_TYPE 2085 Field Length 2086 Vender OS major version 1 2087 Vender OS minor version 1 2088 EIGRP major revision 1 2089 EIGRP minor revision 1 2091 The EIGRP TLV Version fields are used to determine TLV format 2092 versions. Routers using Version 1.2 TLVs do not understand version 2093 2.0 TLVs, therefore Version 2.0 routers must send the packet with 2094 both TLV formats in a mixed network. 2096 A.7.5 0x0005 - MULTICAST_SEQUENCE_TYPE 2097 The next multicast sequence TLV 2099 A.7.6 0x0006 - PEER_INFORMATION_TYPE 2100 This TLV is reserved, and not part of this IETF draft. 2102 A.7.7 0x0007 - PEER_TERMAINATION_TYPE 2103 This TLV is used in HELLO Packets to specify a given neighbor has 2104 been reset. 2106 0 1 2 3 2107 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 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | 0x0007 | Length | 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | Address List (variable) | 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 A.7.8 0x0008 - TID_LIST_TYPE 2115 List of sub-topology identifiers, including the base topology, 2116 supported but the router. 2118 0 1 2 3 2119 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 2120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2121 | 0x0008 | Length | 2122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2123 | Topology Identification List (variable) | 2124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 If this information changes from the last state, it means either a 2127 new topology was added, or an existing topology was removed. This 2128 TLV is ignored until three-way handshake has finished 2130 When the TID list received, it compares the list to the previous list 2131 sent. If a TID is found which does not previously exist, the TID is 2132 added to the neighbor's topology list, and the existing sub-topology 2133 is sent to the peer. 2135 If a TID, which was in a previous list, is not found, the TID is 2136 removed from the neighbor's topology list and all routes learned 2137 though that neighbor for that sub-topology is removed from the 2138 topology table. 2140 A.8 Classic Route Information TLV Types 2141 A.8.1 Classic Flag Field Encoding 2142 EIGRP transports a number of flags with in the TLVs to indicate 2143 addition route state information. These bits are defined as follows: 2145 Flags Field 2146 ----------- 2147 Source Withdraw (Bit 0) - Indicates if the router which is the 2148 original source of the destination is withdrawing the route from the 2149 network, or if the destination is lost due as a result of a network 2150 failure. 2152 Candidate Default (CD) (Bit 1) - If set, this destination should be 2153 regarded as a candidate for the default route. An EIGRP default route 2154 is selected from all the advertised candidate default routes with the 2155 smallest metric. 2157 ACTIVE (Bit 2) - Indicates if the route is in the active state. 2159 A.8.2 Classic Metric Encoding 2160 The handling of bandwidth and delay for Classic TLVs are encoded in 2161 the packet 'scaled' form relative to how they are represented on the 2162 physical link. 2164 0 1 2 3 2165 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 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 | Scaled Delay | 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 | Scaled Bandwidth | 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 | MTU | Hop-Count | 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 | Reliability | Load | Internal Tag | Flags Field | 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 Scaled Delay - An administrative parameter assigned statically on a 2177 per interface type basis to represent the time it takes a along an 2178 unloaded path. This is expressed in units of 10s of microseconds 2179 divvied by 256. A delay of 0xFFFFFFFF indicates an unreachable route. 2181 Scaled Bandwidth - The path bandwidth measured in bits per second. In 2182 units of 2,560,000,000/kbps 2183 MTU - The minimum maximum transmission unit size for the path to the 2184 destination. 2186 Hop Count - The number of router traversals to the destination. 2188 Reliability - The current error rate for the path. Measured as an 2189 error percentage. A value of 255 indicates 100% reliability 2191 Load - The load utilization of the path to the destination, measured 2192 as a percentage. A value of 255 indicates 100% load. 2194 Internal-Tag - A tag assigned by the network administrator that is 2195 untouched by EIGRP. This allows a network administrator to filter 2196 routes in other EIGRP border routers based on this value. 2198 Flag Field - See Section A.8.1 2200 A.8.3 Classic Exterior Encoding 2201 Additional routing information so provided for destinations outside 2202 of the EIGRP autonomous system as follows: 2204 0 1 2 3 2205 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 2206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2207 | Router Identification | 2208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2209 | Autonomous System Number | 2210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2211 | External Protocol Metric | 2212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2213 | Reserved |Extern Protocol| Flags Field | 2214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 Router Identifier (RID) - A unique 32bit number that identifies the 2217 router sourcing the route that has redistributed this external route 2218 into the EIGRP autonomous system. If an IPv4 address is used, the 2219 address SHOULD be the largest unsigned address of any inter-face IPv4 2220 address. 2222 AS Number - The autonomous system number that the route resides in. 2223 Administrator Tag - A tag assigned by the network administrator that 2224 is untouched by EIGRP. This allows a network administrator to filter 2225 routes in other EIGRP border routers based on this value. 2227 External Protocol Metric - 32bit value of the composite metric that 2228 resides in the routing table as learned by the foreign protocol. If 2229 the External Protocol is IGRP or another EIGRP routing process, the 2230 value can optionally be the composite metric or 0, and the metric 2231 information is stored in the metric section. 2233 External Protocol - Defines the external protocol that this route was 2234 learned. See Section A.2 2236 Flag Field - See Section A.8.1 2238 A.8.4 Classic Destination Encoding 2239 EIGRP carries destination in a compressed form, where the number of 2240 bits significant in the variable length address field are indicated 2241 in a counter 2242 0 1 2 3 2243 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 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 | Subnet Mask | Destination Address (variable length | 2246 | Bit Count | ((Bit Count - 1) / 8) + 1 | 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 Subnet Mask Bit Count - 8-bit value used to indicate the number of 2250 bits in the subnet mask. A value of 0 indicates the default network 2251 and no address is present. 2252 Destination Address - A variable length field used o carry the 2253 destination address. The length is determined by the number of 2254 consecutive bits in the destination address, rounded up to the 2255 nearest octet boundary, determines the length of the address. 2257 A.8.5 IPv4 Specific TLVs 2258 INTERNAL_TYPE 0x0102 2259 EXTERNAL_TYPE 0x0103 2260 COMMUNITY_TYPE 0x0104 2262 A.8.5.1 IPv4 INTERNAL_TYPE 2263 This TLV conveys IPv4 destination and associated metric information 2264 for IPv4 networks. Routes advertised in this TLV are network 2265 interfaces that EIGRP is configured on as well as networks that are 2266 learned via other routers running EIGRP. 2268 0 1 2 3 2269 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 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 | 0x01 | 0x02 | Length | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 | Next Hop Forwarding Address | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2275 | Vector Metric Section (See Section A.8.2) | 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2277 | Destination Section | 2278 | IPv4 Address (variable length) | 2279 | (See Section A.8.4) | 2280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2282 Next Hop Forwarding Address - IPv4 address is represented by 4 8-bit 2283 values (total 4 octets). If the value is zero (0), the IPv6 address 2284 from the received IPv4 header is used as the next-hop for the route. 2285 Otherwise, the specified IPv4 address will be used. 2287 Metric Section - vector metrics for destinations contained in this 2288 TLV. See description of metric encoding in section A.8.2 2289 Destination Section - The network/subnet/host destination address 2290 being requested. See description of destination in sectionA.8.4 2292 A.8.5.2 IPv4 EXTERNAL_TYPE 2293 This TLV conveys IPv4 destination and metric information for routes 2294 learned by other routing protocols that EIGRP injects into the AS. 2295 Available with this information is the identity of the routing 2296 protocol that created the route, the external metric, the AS number, 2297 an indicator if it should be marked as part of the EIGRP AS, and a 2298 network administrator tag used for route filtering at EIGRP AS 2299 boundaries. 2301 0 1 2 3 2302 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 2303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2304 | 0x01 | 0x03 | Length | 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 | Next Hop Forwarding Address | 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2308 | Exterior Section (See Section A.8.3) | 2309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2310 | Vector Metric Section (See Section A.8.2) | 2311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2312 | Destination Section | 2313 | IPv4 Address (variable length) | 2314 | (See Section A.8.4) | 2315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2317 Next Hop Forwarding Address - IPv4 address is represented by 4 8-bit 2318 values (total 4 octets). If the value is zero (0), the IPv6 address 2319 from the received IPv4 header is used as the next-hop for the route. 2320 Otherwise, the specified IPv4 address will be used 2322 Exterior Section - Additional routing information provide for a 2323 destination outside of the EIGRP autonomous system and that has been 2324 redistributed into the EIGRP. See Section A.8.3 2326 Metric Section - vector metrics for destinations contained in this 2327 TLV. See description of metric encoding in section A.8.2 2329 Destination Section - The network/subnet/host destination address 2330 being requested. See description of destination in Section A.8.4 2332 A.8.5.3 IPv4 COMMUNITY_TYPE 2333 This TLV is used to provide community tags for specific IPv4 2334 destinations. 2336 0 1 2 3 2337 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 2338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2339 | 0x01 | 0x04 | Length | 2340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2341 | IPv4 Destination | 2342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 | Reserved | Community Length | 2344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2345 | Community List | 2346 | (variable length) | 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 Destination - The IPv4 address the community information should be 2350 stored with. 2352 Community Length - 2 octet unsigned number that indicates the length 2353 of the Community List. The length does not includes the IPv4 Address, 2354 reserved, or Length fields 2356 Community List - One or more 8 octet EIGRP community as defined in 2357 section A.4 2359 A.8.6 IPv6 Specific TLVs 2360 REQUEST_TYPE 0x0401 2361 INTERNAL_TYPE 0x0402 2362 EXTERNAL_TYPE 0x0403 2364 A.8.6.1 IPv6 INTERNAL_TYPE 2365 This TLV conveys IPv6 destination and associated metric information 2366 for IPv6 networks. Routes advertised in this TLV are network 2367 interfaces that EIGRP is configured on as well as networks that are 2368 learned via other routers running EIGRP. 2370 0 1 2 3 2371 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 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2373 | 0x04 | 0x02 | Length | 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 | Next Hop Forwarding Address | 2376 | (16 octets) | 2377 | | 2378 | | 2379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2380 | Vector Metric Section (See Section A.8.2) | 2381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2382 | Destination Section | 2383 | IPv4 Address (variable length) | 2384 | (See Section A.8.4) | 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 Next Hop Forwarding Address - IPv6 address is represented by 8 groups 2387 of 16-bit values (total 16 octets). If the value is zero (0), the 2388 IPv6 address from the received IPv6 header is used as the next-hop 2389 for the route. Otherwise, the specified IPv6 address will be used. 2391 Metric Section - vector metrics for destinations contained in this 2392 TLV. See description of metric encoding in section A.8.2 2394 Destination Section - The network/subnet/host destination address 2395 being requested. See description of destination in section A.8.4 2397 A.8.6.2 IPv6 EXTERNAL_TYPE 2398 This TLV conveys IPv6 destination and metric information for routes 2399 learned by other routing protocols that EIGRP injects into the AS. 2400 Available with this information is the identity of the routing 2401 protocol that created the route, the external metric, the AS number, 2402 an indicator if it should be marked as part of the EIGRP AS, and a 2403 network administrator tag used for route filtering at EIGRP AS 2404 boundaries. 2406 0 1 2 3 2407 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2409 | 0x04 | 0x03 | Length | 2410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2411 | Next Hop Forwarding Address | 2412 | (16 octets) | 2413 | | 2414 | | 2415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 | Exterior Section (See Section A.8.3) | 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2418 | Vector Metric Section (See Section A.8.2) | 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2420 | Destination Section | 2421 | IPv4 Address (variable length) | 2422 | (See Section A.8.4) | 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2425 Next Hop Forwarding Address - IPv6 address is represented by 8 groups 2426 of 16-bit values (total 16 octets). If the value is zero (0), the 2427 IPv6 address from the received IPv6 header is used as the next-hop 2428 for the route. Otherwise, the specified IPv6 address will be used. 2430 Exterior Section - Additional routing information provide for a 2431 destination outside of the EIGRP autonomous system and that has been 2432 redistributed into the EIGRP. See Section A.8.3 2433 Metric Section - vector metrics for destinations contained in this 2434 TLV. See description of metric encoding in section A.8.2 2436 Destination Section - The network/subnet/host destination address 2437 being requested. See description of destination in section A.8.4 2439 A.8.6.3 IPv6 COMMUNITY_TYPE 2440 This TLV is used to provide community tags for specific IPv4 2441 destinations. 2443 0 1 2 3 2444 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 2445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 | 0x01 | 0x04 | Length | 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2448 | Destination | 2449 | (16 octets) | 2450 | | 2451 | | 2452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2453 | Reserved | Community Length | 2454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2455 | Community List | 2456 | (variable length) | 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2459 Destination - The IPv6 address the community information should be 2460 stored with. 2462 Community Length - 2 octet unsigned number that indicates the length 2463 of the Community List. The length does not includes the IPv4 Address, 2464 Reserved or Length fields 2466 Community List - One or more 8 octet EIGRP community as defined in 2467 section A.4 2468 A.9 Multi-Protocol Route Information TLV Types 2469 This TLV conveys topology and associated metric information 2471 0 1 2 3 2472 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 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 |Header Version | Opcode | Checksum | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 | Flags | 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2478 | Sequence Number | 2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 | Acknowledgement number | 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 | Virtual Router ID | Autonomous system number | 2483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 | TLV Header Encoding | 2485 | (See Section A.9.1) | 2486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2487 | Wide Metric Encoding | 2488 | (See Section A.9.2) | 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 | Destination Descriptor | 2491 | (variable length) | 2492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 A.9.1 TLV Header Encoding 2495 There has been a long-standing requirement for EIGRP to support 2496 routing technologies such as multi-topologies and provide the ability 2497 to carry destination information independent of the transport. To 2498 accomplish this, a Vector has been extended to have a new "Header 2499 Extension Header" section. This is a variable length field and, at a 2500 minimum, will support the following fields: 2502 0 1 2 3 2503 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 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 | Type high | Type low | Length | 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2507 | AFI | TID | 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 | Router Identifier | 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 | Value (variable length) | 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2513 The available fields are: 2514 TYPE - Topology TLVs have the following TYPE codes: 2516 REQUEST_TYPE 0x0601 2517 INTERNAL_TYPE 0x0602 2518 EXTERNAL_TYPE 0x0603 2520 Address Family Identifier (AFI) - defines the type and format for the 2521 destination data. In EIGRP, each address family is implemented as a 2522 Protocol Dependent Module. 2523 Topology Identifier (TID) - The Service specific prefixes from the 2524 service specific topology tables will be tagged with a number known 2525 as the Topology Identifier (TID). This value was originally 2526 introduced with MTR. 2527 Router Identifier (RID) - A unique 32bit number that identifies the 2528 router sourcing the route into this EIGRP autonomous system. 2530 A.9.2 Wide Metric Encoding 2531 Multi-Protocol TLV's will provide an extendable section of metric 2532 information, which is not used for the primary routing compilation. 2533 Additional per path information is included to enable per-path cost 2534 calculations in the future. Use of the per-path costing along with 2535 the VID/TID will prove a complete solution for multidimensional 2536 routing. 2538 0 1 2 3 2539 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 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 | Offset | Priority | Reliability | Load | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | MTU | Hop-Count | 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | Delay | 2546 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | | | 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2549 | Bandwidth | 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 | Reserved | Opaque Flags | 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 | Extended Attributes | 2554 | (variable length) | 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 The fields are: 2558 Offset - Number of 16bit words in the Extended Attribute section, 2559 used to determine the start of the destination information. If no 2560 Extended Attributes are attached, offset will be zero. 2562 Priority - Priority of the prefix when transmitting a group of 2563 destination addresses to neighboring routers. A priority of zero 2564 indicates no priority is set. Currently transmitted as 0 2566 Reliability - The current error rate for the path. Measured as an 2567 error percentage. A value of 255 indicates 100% reliability 2569 Load - The load utilization of the path to the destination, measured 2570 as a percentage. A value of 255 indicates 100% load. 2572 MTU - The minimum maximum transmission unit size for the path to the 2573 destination. Not used in metric calculation, but available to 2574 underlying protocols 2576 Hop Count - The number of router traversals to the destination. 2578 Delay - The one-way latency along an unloaded path to the destination 2579 expressed in units of picoseconds per kilobit. This number is not 2580 scaled, as is the case with "scaled delay". A delay of 0xFFFFFFFFFFFF 2581 indicates an unreachable route. 2583 Bandwidth - The path bandwidth measured in kilobit per second as 2584 presented by the interface. This number is not scaled, as is the 2585 case with "scaled bandwidth". A bandwidth of 0xFFFFFFFFFFFF indicates 2586 an unreachable route. 2588 Reserved - Transmitted as 0x0000 2590 Opaque Flags - 16 bit protocol specific flags. 2592 Extended Attributes - (Optional) When present, defines extendable per 2593 destination attributes. This field is not normally transmitted. 2595 A.9.3 Extended Metrics 2596 Extended metrics allows for extensibility of EIGRP metrics in a manor 2597 similar to RFC-6390[8]. Each Extended metric shall consist of a 2598 standard Type-Length header followed by application-specific 2599 information. The information field may be used directly by EIGRP, or 2600 by other applications. Extended metrics values not understood must be 2601 treated as opaque and passed along with the associated route. 2603 The general formats for the Extended Metric fields are: 2605 0 1 2 3 2606 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 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 | Opcode | Offset | Data | 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 Opcode - Indicates the type of Extended Metric 2613 Offset - Number of 16bit words in the sub-field. Offset does not 2614 include the length of the opcode or offset fields) 2616 Data - Zero or more octets of data as defined by Opcode 2618 A.9.3.1 0x00 - NoOp 2619 This is used to pad the attribute section to ensure 32-bit alignment 2620 of the metric encoding section. 2622 0 1 2 3 2623 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2625 | 0x00 | 0x00 | 2626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2628 The fields are: 2629 Opcode - Transmitted as zero (0) 2631 Offset - Transmitted as zero (0) indicating no data is present 2633 Data - No data is present with this attribute. 2635 A.9.3.2 0x01 - Scaled Metric 2636 If a route is received from a back-rev neighbor, and the route is 2637 selected as the best path, the scaled metric received in the older 2638 UPDATE, MAY be attached to the packet. If received, the value is for 2639 informational purposes, and is not affected by K6 2640 0 1 2 3 2641 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 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 | 0x01 | 0x04 | Reserved | 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2645 | Scaled Bandwidth | 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 | Scaled Delay | 2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 Reserved - Transmitted as 0x0000 2652 Scaled Delay - An administrative parameter assigned statically on a 2653 per interface type basis to represent the time it takes a along an 2654 unloaded path. This is expressed in units of 10s of microseconds 2655 divvied by 256. A delay of 0xFFFFFFFF indicates an unreachable route. 2657 Scaled Bandwidth - The minimum bandwidth along a path expressed in 2658 units of 2,560,000,000/kbps. A bandwidth of 0xFFFFFFFF indicates an 2659 unreachable route. 2661 A.9.3.3 0x02 - Administrator Tag 2662 This is used to provide and administrative tags for specific topology 2663 entries. It is not affected by K6 2665 0 1 2 3 2666 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 2667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2668 | 0x02 | 0x02 | Administrator Tag | 2669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2670 | Administrator Tag (cont) | 2671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 Administrator Tag - A tag assigned by the network administrator that 2674 is untouched by EIGRP. This allows a network administrator to filter 2675 routes in other EIGRP border routers based on this value. 2677 A.9.3.4 0x03 - Community List 2678 This is used to provide communities for specific topology entries. It 2679 is not affected by K6 2681 0 1 2 3 2682 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 2683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 | 0x03 | Offset | Community List | 2685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2686 | (variable length) | 2687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2688 Offset - Number of 16bit words in the sub-field. Currently 2689 transmitted as 4 2690 Community List - One or more community values as defined in section 2691 A.4 2693 A.9.3.5 0x04 - Jitter 2694 0 1 2 3 2695 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 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 | 0x04 | 0x03 | Jitter | 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2699 | | 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2702 Jitter - The measure of the variability over time of the latency 2703 across a network measured in measured in microseconds. 2705 A.9.3.6 0x05 - Quiescent Energy 2706 0 1 2 3 2707 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 2708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 | 0x05 | 0x02 | Q-Energy (high) | 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2711 | Q-Energy (low) | 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2714 Q-Energy - Paths with higher idle (standby) energy usage will be 2715 reflected in a higher aggregate metric than those having lower energy 2716 usage. If present, this number will represent the idle power 2717 consumption expressed in milliwatts per kilobit. 2719 A.9.3.7 0x06 - Energy 2720 0 1 2 3 2721 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 2722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2723 | 0x06 | 0x02 | Energy (high) | 2724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2725 | Energy (low) | 2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2728 Energy - Paths with higher active energy usage will be reflected in a 2729 higher aggregate metric than those having lower energy usage. If 2730 present, this number will represent the power consumption expressed 2731 in milliwatts per kilobit. 2733 A.9.3.8 0x07 - AddPath 2734 The Add Path enables EIGRP to advertise multiple best paths to 2735 adjacencies. There will be up to a maximum of 4 AddPath supported, 2736 where the format of the field will be as follows; 2738 0 1 2 3 2739 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 2740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2741 | 0x07 | Offset | AddPath (Variable Length) | 2742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2744 Offset - Number of 16bit words in the sub-field. Currently 2745 transmitted as 4 2747 AddPath - Length of this field will vary in length based on weather 2748 it contains IPv4 or IPv6 data. 2750 A.9.3.8.1 Addpath with IPv4 Next-hop 2752 0 1 2 3 2753 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 2754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2755 | 0x07 | Offset | Next-hop Address(Upper 2 byes) | 2756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2757 | IPv4 Address (Lower 2 byes) | RID (Upper 2 byes) | 2758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2759 | RID (Upper 2 byes) | Admin Tag (Upper 2 byes) | 2760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2761 | Admin Tag (Upper 2 byes) |Extern Protocol| Flags Field | 2762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+ 2764 Next Hop Address - IPv4 address is represented by 4 8-bit values 2765 (total 4 octets). If the value is zero(0), the IPv6 address from the 2766 received IPv4 header is used as the next-hop for the route. 2767 Otherwise, the specified IPv4 address will be used. 2769 RID - A unique 32bit number that identifies the router sourcing the 2770 route that has redistributed this external route into the EIGRP 2771 autonomous system. The address should be the largest unsigned address 2772 of any inter-face IPv4 address. 2774 Administrator Tag - A tag assigned by the network administrator that 2775 is untouched by EIGRP. This allows a network administrator to filter 2776 routes in other EIGRP border routers based on this value. 2777 If the route is of type external, then 2 addition bytes will be add 2778 as follows: 2780 External Protocol - Defines the external protocol that this route was 2781 learned. See Section A.2 2783 Flag Field - See Section A.8.1 2785 A.9.3.8.2 Addpath with IPv6 Next-hop 2786 0 1 2 3 2787 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 2788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2789 | 0x07 | Offset | Next-hop Address | 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2791 | | 2792 | (16 octets) | 2793 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2794 | | RID (Upper 2 byes) | 2795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 | RID (Upper 2 byes) | Admin Tag (Upper 2 byes) | 2797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 | Admin Tag (Upper 2 byes) |Extern Protocol| Flags Field | 2799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2801 Next Hop Address - IPv6 address is represented by 8 groups of 16-bit 2802 values (total 16 octets). If the value is zero(0), the IPv6 address 2803 from the received IPv6 header is used as the next-hop for the route. 2804 Otherwise, the specified IPv6 address will be used. 2806 RID - A unique 32bit number that identifies the router sourcing the 2807 route that has redistributed this external route into the EIGRP 2808 autonomous system. The address should be the largest unsigned address 2809 of any inter-face IPv4 address. 2811 Administrator Tag - A tag assigned by the network administrator that 2812 is untouched by EIGRP. This allows a network administrator to filter 2813 routes in other EIGRP border routers based on this value. 2814 If the route is of type external, then 2 addition bytes will be add 2815 as follows: 2817 External Protocol - Defines the external protocol that this route was 2818 learned. See Section A.2 2820 Flag Field - See Section A.8.1 2821 A.9.4 Exterior Encoding 2822 Additional routing information so provided for destinations outside 2823 of the EIGRP autonomous system as follows: 2824 0 1 2 3 2825 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 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 | Router Identification | 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 | Autonomous System Number | 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2831 | External Protocol Metric | 2832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2833 | Reserved |Extern Protocol| Flags Field| 2834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2836 Router Identifier (RID) - A unique 32bit number which identifies the 2837 router sourcing the route, or which has redistributed this external 2838 route into the EIGRP autonomous system. 2840 AS Number - The autonomous system number that the route resides in. 2842 Administrator Tag - A tag assigned by the network administrator that 2843 is untouched by EIGRP. This allows a network administrator to filter 2844 routes in other EIGRP border routers based on this value. 2846 External Protocol Metric - 32bit value of the composite metric that 2847 resides in the routing table as learned by the foreign protocol. If 2848 the External Protocol is IGRP or another EIGRP routing process, the 2849 value can optionally be the composite metric or 0, and the metric 2850 information is stored in the metric section. 2852 External Protocol - Defines the external protocol that this route was 2853 learned. See Section A.2 2855 Flag Field - See Section A.8.1 2857 A.9.5 Destination Encoding 2858 Destination information is encoded in Multi-Protocol packets in the 2859 same manner as used by Classic TLVs. This is accomplished by using a 2860 counter to indicate how many significant bits are present in the 2861 variable length address field 2863 0 1 2 3 2864 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 2865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2866 | Subnet Mask | Destination Address (variable length | 2867 | Bit Count | ((Bit Count - 1) / 8) + 1 | 2868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2869 Subnet Mask Bit Count - 8-bit value used to indicate the number of 2870 bits in the subnet mask. A value of 0 indicates the default network 2871 and no address is present. 2873 Destination Address - A variable length field used o carry the 2874 destination address. The length is determined by the number of 2875 consecutive bits in the destination address, rounded up to the 2876 nearest octet boundary, determines the length of the address. 2878 A.9.6 Route Information 2880 A.9.6.1 INTERNAL TYPE 2881 This TLV conveys destination information based on the IANA AFI 2882 defined in the TLV Header (See Section A.9.1), and associated metric 2883 information. Routes advertised in this TLV are network interfaces 2884 that EIGRP is configured on as well as networks that are learned via 2885 other routers running EIGRP. 2887 A.9.6.2 EXTERNAL TYPE 2888 This TLV conveys destination information based on the IANA AFI 2889 defined in the TLV Header (See Section A.9.1), and metric 2890 information for routes learned by other routing protocols that EIGRP 2891 injects into the AS. Available with this information is the identity 2892 of the routing protocol that created the route, the external metric, 2893 the AS number, an indicator if it should be marked as part of the 2894 EIGRP AS, and a network administrator tag used for route filtering at 2895 EIGRP AS boundaries. 2897 Author's Address 2898 Donnie V Savage 2899 Cisco Systems, Inc 2900 7025 Kit Creed Rd, RTP, NC 2902 Phone: 919-392-2379 2903 Email: dsavage@cisco.com 2905 Donald Slice 2906 Cisco Systems, Inc 2907 7025 Kit Creed Rd, RTP, NC 2909 Phone: 919-392-2539 2910 Email: dslice@cisco.com 2912 Steven Moore 2913 Cisco Systems, Inc 2914 7025 Kit Creed Rd, RTP, NC 2916 Phone: 919-392-2674 2917 Email: smoore@cisco.com 2919 James Ng 2920 Cisco Systems, Inc 2921 7025 Kit Creed Rd, RTP, NC 2923 Phone: 919-392-2582 2924 Email: jamng@cisco.com 2926 Russ White 2927 VCE 2928 RTP, NC 2930 Phone: 1-877-308-0993 2931 Email: russw@riw.us