idnits 2.17.1 draft-savage-eigrp-03.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 1 longer page, the longest (page 1) being 3529 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 Authors' Addresses Section. ** There are 1166 instances of too long lines in the document, the longest one being 19 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. == There are 9 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 271 has weird spacing: '... toward whic...' == Line 272 has weird spacing: '...lity of two ...' == Line 273 has weird spacing: '...ity and comp...' == Line 274 has weird spacing: '...rs with inte...' == Line 275 has weird spacing: '...rs. Two neig...' == (30 more instances...) -- The document date (16 Aug 2015) is 3176 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '11' is mentioned on line 563, but not defined == Missing Reference: '12' is mentioned on line 610, but not defined == Missing Reference: '13' is mentioned on line 671, but not defined == Missing Reference: '14' is mentioned on line 712, but not defined == Missing Reference: '15' is mentioned on line 770, but not defined == Missing Reference: '16' is mentioned on line 794, but not defined == Missing Reference: '17' is mentioned on line 853, but not defined == Missing Reference: '18' is mentioned on line 912, but not defined == Missing Reference: '19' is mentioned on line 967, but not defined == Missing Reference: '20' is mentioned on line 1024, but not defined == Missing Reference: '21' is mentioned on line 1079, but not defined == Missing Reference: '22' is mentioned on line 1116, but not defined == Missing Reference: '23' is mentioned on line 1176, but not defined == Missing Reference: '24' is mentioned on line 1238, but not defined == Missing Reference: '25' is mentioned on line 1294, but not defined == Missing Reference: '26' is mentioned on line 1353, but not defined == Missing Reference: '27' is mentioned on line 1414, but not defined == Missing Reference: '28' is mentioned on line 1472, but not defined == Missing Reference: '29' is mentioned on line 1528, but not defined == Missing Reference: '30' is mentioned on line 1583, but not defined == Missing Reference: '31' is mentioned on line 1642, but not defined == Missing Reference: '32' is mentioned on line 1701, but not defined == Missing Reference: '33' is mentioned on line 1740, but not defined == Missing Reference: '34' is mentioned on line 1799, but not defined == Missing Reference: '35' is mentioned on line 1853, but not defined == Missing Reference: '36' is mentioned on line 1877, but not defined == Missing Reference: 'RFC2119' is mentioned on line 1892, but not defined == Missing Reference: 'RFC5234' is mentioned on line 1895, but not defined == Missing Reference: '37' is mentioned on line 1922, but not defined == Missing Reference: '38' is mentioned on line 1948, but not defined == Missing Reference: '39' is mentioned on line 1997, but not defined == Missing Reference: '40' is mentioned on line 2053, but not defined == Missing Reference: '41' is mentioned on line 2107, but not defined == Missing Reference: '42' is mentioned on line 2164, but not defined == Missing Reference: '43' is mentioned on line 2223, but not defined == Missing Reference: '44' is mentioned on line 2279, but not defined == Missing Reference: '45' is mentioned on line 2334, but not defined == Missing Reference: '46' is mentioned on line 2394, but not defined == Missing Reference: '47' is mentioned on line 2430, but not defined == Missing Reference: '48' is mentioned on line 2491, but not defined == Missing Reference: '49' is mentioned on line 2531, but not defined == Missing Reference: '50' is mentioned on line 2593, but not defined == Missing Reference: '51' is mentioned on line 2634, but not defined == Missing Reference: '52' is mentioned on line 2692, but not defined == Missing Reference: '53' is mentioned on line 2753, but not defined == Missing Reference: '54' is mentioned on line 2811, but not defined == Missing Reference: '55' is mentioned on line 2865, but not defined == Missing Reference: '56' is mentioned on line 2923, but not defined == Missing Reference: '57' is mentioned on line 2975, but not defined == Missing Reference: '58' is mentioned on line 3028, but not defined == Missing Reference: '59' is mentioned on line 3046, but not defined == Missing Reference: '60' is mentioned on line 3091, but not defined == Unused Reference: 'RFC3692' is defined on line 1909, but no explicit reference was found in the text == Unused Reference: 'RFC6390' is defined on line 1917, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 65 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force D. Savage 2 Internet-Draft J. Ng 3 Intended status: Informational S. Moore 4 Expires: Febuary, 2016 Cisco Systems 5 D. Slice 6 Cumulus Networks 7 P. Paluch 8 University of Zilina 9 R. White 10 Ericsson 11 16 Aug 2015 13 Enhanced Interior Gateway Routing Protocol 14 draft-savage-eigrp-03.txt 16 Abstract 18 This document describes the protocol design and architecture for 19 Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a routing 20 protocol based on Distance Vector technology. The specific algorithm 21 used is called DUAL, a Diffusing Update Algorithm [4]. The algorithm 22 and procedures were researched, developed, and simulated by SRI 23 International. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [1]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering Task 37 Force (IETF). Note that other groups may also distribute working 38 documents as Internet-Drafts. The list of current Internet-Drafts is 39 at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on Febuary 16, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the document 51 authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 54 Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on 55 the date of publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect to this 57 document. Code Components extracted from this document must include Simplified 58 BSD License text as described in Section 4.e of the Trust Legal Provisions and 59 are provided without warranty as described in the Simplified BSD License. 61 This document may not be modified, and derivative works of it may not be 62 created, except to format it for publication as an RFC or to translate it into 63 languages other than English. 65 Savage, et al. Expires August 16, 2015 [1] 66 Table of Contents 68 1 Introduction ........................................................ 5 69 2 Terminology ......................................................... 5 70 3 The DUAL Diffusing Update Algorithm ................................. 8 71 3.1 Algorithm Description ........................................... 8 72 3.2 Route States .................................................... 8 73 3.3 Feasibility Condition ........................................... 9 74 3.4 DUAL Message Types ............................................. 11 75 3.5 DUAL Finite State Machine (FSM) ................................ 11 76 3.6 DUAL Operation - Example Topology .............................. 15 77 4 EIGRP Packets ...................................................... 17 78 4.1 UPDATE Packets ................................................. 17 79 4.2 QUERY Packets .................................................. 17 80 4.3 REPLY Packets .................................................. 18 81 4.4 Exception Handling ............................................. 18 82 4.4.1 Active Duration (Stuck-in-Active) .......................... 18 83 4.4.1.1 SIA-QUERY .............................................. 18 84 4.4.1.2 SIA-REPLY .............................................. 19 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 ............................... 25 89 5.3 Neighbor Discovery/Recovery .................................... 25 90 5.3.1 Neighbor Hold Time ......................................... 26 91 5.3.2 HELLO Packets .............................................. 26 92 5.3.3 UPDATE Packets ............................................. 26 93 5.3.3.1 NULL Update ............................................ 26 94 5.3.4 Initialization Sequence .................................... 26 95 5.3.5 Neighbor Formation ......................................... 27 96 5.3.6 QUERY Packets During Neighbor Formation .................... 28 97 5.4 Topology Table ................................................. 28 98 5.4.7 Route Management ........................................... 28 99 5.4.7.1 Internal Routes ........................................ 28 100 5.4.7.2 External routes ........................................ 29 101 5.4.7.3 Split Horizon and Poison Reverse ....................... 29 102 5.4.7.3.1 Startup Mode ....................................... 30 103 5.4.7.3.2 Advertising Topology Table Change .................. 30 104 5.4.7.3.3 Sending a QUERY/UPDATE ............................. 30 105 5.5 EIGRP Metric Coefficients ...................................... 30 106 5.5.1 Coefficients K1 and K2 ..................................... 31 107 5.5.2 Coefficient K3 ............................................. 31 108 5.5.3 Coefficients K4 and K5 ..................................... 31 109 5.5.4 Coefficient K6 ............................................. 31 110 5.5.4.1 Jitter ................................................. 31 111 5.5.4.2 Energy ................................................. 32 112 5.6 EIGRP Metric Calculations ...................................... 32 113 5.6.1 Classic Metrics ............................................ 32 114 5.6.1.1 Classic Composite Formulation .......................... 32 116 Savage, et al. Expires August 16, 2015 [2] 117 5.6.2 Wide Metrics ............................................... 34 118 5.6.2.1 Wide Metric Vectors .................................... 34 119 5.6.2.2 Wide Metric Conversion Constants ....................... 35 120 5.6.2.3 Throughput Calculation ................................. 35 121 5.6.2.4 Latency Calculation .................................... 35 122 5.6.2.5 Composite Calculation .................................. 36 123 6 Security Considerations ............................................ 36 124 7 IANA Considerations ................................................ 37 125 8 References ......................................................... 37 126 8.1 Normative References ........................................... 37 127 8.2 Informative References ......................................... 37 128 9 Acknowledgments .................................................... 38 129 10 EIGRP Packet Formats .............................................. 39 130 10.1 Protocol Number ............................................... 39 131 10.2 Protocol Assignment Encoding .................................. 39 132 10.3 Destination Assignment Encoding ............................... 39 133 10.4 EIGRP Communities Attribute ................................... 40 134 10.5 EIGRP Packet Header ........................................... 40 135 10.6 EIGRP TLV Encoding Format ..................................... 42 136 10.6.1 Type Field Encoding ....................................... 42 137 10.6.2 Length Field Encoding ..................................... 42 138 10.6.3 Value Field Encoding ...................................... 43 139 10.7 EIGRP Generic TLV Definitions ................................. 43 140 10.7.1 0x0001 - PARAMETER_TYPE ................................... 43 141 10.7.2 0x0002 - AUTHENTICATION_TYPE .............................. 43 142 10.7.2.1 0x02 - MD5 Authentication Type ........................ 44 143 10.7.2.2 0x03 - SHA2 Authentication Type ....................... 44 144 10.7.3 0x0003 - SEQUENCE_TYPE .................................... 44 145 10.7.4 0x0004 - SOFTWARE_VERSION_TYPE ............................ 44 146 10.7.5 0x0005 - MULTICAST_SEQUENCE_TYPE .......................... 44 147 10.7.6 0x0006 - PEER_INFORMATION_TYPE ............................ 44 148 10.7.7 0x0007 - PEER_TERMAINATION_TYPE ........................... 45 149 10.7.8 0x0008 - TID_LIST_TYPE .................................... 45 150 10.8 Classic Route Information TLV Types ........................... 45 151 10.8.1 Classic Flag Field Encoding ............................... 45 152 10.8.2 Classic Metric Encoding ................................... 46 153 10.8.3 Classic Exterior Encoding ................................. 46 154 10.8.4 Classic Destination Encoding .............................. 47 155 10.8.5 IPv4 Specific TLVs ........................................ 48 156 10.8.5.1 IPv4 INTERNAL_TYPE .................................... 48 157 10.8.5.2 IPv4 EXTERNAL_TYPE .................................... 48 158 10.8.5.3 IPv4 COMMUNITY_TYPE ................................... 49 159 10.8.6 IPv6 Specific TLVs ........................................ 50 160 10.8.6.1 IPv6 INTERNAL_TYPE .................................... 50 161 10.8.6.2 IPv6 EXTERNAL_TYPE .................................... 50 162 10.8.6.3 IPv6 COMMUNITY_TYPE ................................... 51 163 10.9 Multi-Protocol Route Information TLV Types .................... 52 164 10.9.1 TLV Header Encoding ....................................... 52 165 10.9.2 Wide Metric Encoding ...................................... 53 166 10.9.3 Extended Metrics .......................................... 54 168 Savage, et al. Expires August 16, 2015 [3] 169 10.9.3.1 0x00 NoOp ............................................ 54 170 10.9.3.2 0x01 Scaled Metric ................................... 54 171 10.9.3.3 0x02 Administrator Tag ............................... 55 172 10.9.3.4 0x03 Community List .................................. 55 173 10.9.3.5 0x04 Jitter .......................................... 55 174 10.9.3.6 0x05 Quiescent Energy ................................ 56 175 10.9.3.7 0x06 Energy .......................................... 56 176 10.9.3.8 0x07 AddPath ......................................... 56 177 10.9.3.8.1 Addpath with IPv4 Next-hop ......................... 56 178 10.9.3.8.2 Addpath with IPv6 Next-hop .......................... 57 179 10.9.4 Exterior Encoding .......................................... 58 180 10.9.5 Destination Encoding ....................................... 58 181 10.9.6 Route Information .......................................... 59 182 10.9.6.1 INTERNAL TYPE .......................................... 59 183 10.9.6.2 EXTERNAL TYPE .......................................... 59 185 Savage, et al. Expires August 16, 2015 [4] 186 1 Introduction 187 This document describes the Enhanced Interior Gateway Routing Protocol (EIGRP), 188 a routing protocol designed and developed by Cisco Systems. DUAL, the algorithm 189 used to converge the control plane to a single set of loop free paths is based 190 on research conducted at SRI International. The Diffusing Update Algorithm 191 (DUAL) is the algorithm used to obtain loop-freedom at every instant throughout 192 a route computation [3]. This allows all routers involved in a topology change 193 to synchronize at the same time; the routers not affected by topology changes 194 are not involved in the recalculation. This document describes the protocol that 195 implements these functions. 197 2 Terminology 198 The following list describes acronyms and definitions for terms used throughout 199 this document: 201 ACTIVE State 202 The local state of a route on a router triggered by any event that causes 203 all neighbors providing the current least cost path to fail the Feasibility 204 Condition check. A route in Active state is considered unusable. During Active 205 state, the router is actively attempting to compute the least cost loop-free 206 path by explicit coordination with its neighbors using Query and Reply messages. 208 Address Family Identifier (AFI) 209 Identity of the network layer network layer reachability information 210 associated with the network layer reachability information being advertised [10]. 212 Autonomous System (AS) 213 A collection of routers exchanging routes under the control of one or more 214 network administrators on behalf of a single administrative entity. 216 Base Topology 217 A routing domain representing a physical (non-virtual) view of the network 218 topology consisting of attached devices and network segments EIGRP uses to form 219 neighbor relationships. Destinations exchanged within the Base Topology are 220 identified with a Topology Identifier value of zero (0). 222 Computed Distance (CD) 223 Total distance (metric) along a path from the current router to 224 a destination network through a particular neighbor computed using that 225 neighbor's Reported Distance and the cost of the link between the two routers. 226 Exactly one Computed Distance is computed and maintained per the [Destination, 227 Advertising Neighbor] pair. 229 Diffusing Computation 230 A distributed computation in which a single starting node commences the 231 computation by delegating subtasks of the computation to its neighbors that may 232 in turn recursively delegate sub-subtasks further, including a signaling scheme 233 allowing the starting node to detect that the computation has finished while 234 avoiding false terminations. In DUAL, the task of coordinated updates of routing 235 tables and resulting best path computation is performed as a diffusing 236 computation. 238 Diffusing Update Algorithm (DUAL) 239 A loop-free routing algorithm used with distance vectors or link states that 240 provides a diffused computation of a routing table. It works very well in the 241 presence of multiple topology changes with low overhead. The technology was 242 researched and developed at SRI International. 244 Savage, et al. Expires August 16, 2015 [5] 245 Downstream Router 246 A router that is one or more hops away from the router in question in the 247 direction of the destination. 249 EIGRP 250 Enhanced Interior Gateway Routing Protocol. 252 Feasibility Condition 253 The Feasibility Condition is a sufficient condition used by a router to 254 verify whether a neighboring router provides a loop-free path to a destination. 255 EIGRP uses the Source Node Condition described in [4] stating that a neighboring 256 router meets the Feasibility Condition if the neighbor's Reported Distance is 257 less than this router's Feasible Distance. 259 Feasible Distance (FD) 260 Defined as the lowest known total metric to a destination from the current 261 router since the last transition from ACTIVE to PASSIVE state. Being effectively 262 a record of the smallest known metric since the last time the network entered 263 the PASSIVE state, the FD is not necessarily a metric of the current best path. 264 Exactly one Feasible Distance is computed per destination network. 266 Feasible Successor 267 A neighboring router that meets the Feasibility Condition for a particular 268 destination, hence providing a guaranteed loop-free path. 270 Neighbor / Peer 271 For a particular router, another router toward which an EIGRP session, also 272 known as adjacency, is established. The ability of two routers to become 273 neighbors depends on their mutual connectivity and compatibility of selected 274 EIGRP configuration parameters. Two neighbors with interfaces connected to a 275 common subnet are known as adjacent neighbors. Two neighbors that are multiple 276 hops apart are known as remote neighbors. 278 PASSIVE state 279 The local state of a route in which at least one neighbor providing the 280 current least cost path passes Feasibility Condition check. A route in PASSIVE 281 state is considered usable and not in need of a coordinated re-computation. 283 Reachability Information (NLRI) 284 Information a router uses to calculate the global routing table to make routing 285 and forwarding decisions. 287 Reported Distance (RD) 288 For a particular destination, the value representing the router's distance 289 to the destination as advertised in all messages carrying routing information. 290 Reported Distance is not equivalent to the current distance of the router to the 291 destination and may be different from it during the process of path re- 292 computation. Exactly one Reported Distance is computed and maintained per 293 destination network. 295 Sub-Topology 296 For a given Base Topology, a sub-topology is characterized by an independent 297 set of router and links in a network for which EIGRP performs an independent 298 path calculation. This allows each sub-topology to implement class-specific 299 topologies to carry class specific traffic. 301 Successor 302 For a particular destination, a neighboring router that meets the 303 Feasibility Condition and, at the same time, provides the least cost path. 305 Savage, et al. Expires August 16, 2015 [6] 306 Stuck In Active (SIA) 307 A destination that has remained in the ACTIVE State in excess of a 308 predefined time period at the local router (Cisco implements this as 3 minutes) 310 Successor Directed Acyclic Graph (SDAG) 311 For a particular destination, a graph defined by routing table contents of 312 individual routers in the topology, such that nodes of this graph are the 313 routers themselves, and a directed edge from router X to router Y exists if and 314 only if router Y is router X's successor. After the network has converged, in 315 the absence of topological changes, SDAG is a tree. 317 Topology Change / Topology Change Event 318 Any event that causes the Computed Distance for a destination through a 319 neighbor to be added modified or removed. As an example, detecting a link cost 320 change, receiving any EIGRP message from a neighbor advertising an updated 321 neighbor's Reported Distance 323 Topology Identifier (TID) 324 A number that is used to mark prefixes as belonging to a specific sub- 325 topology. 327 Topology Table 328 A data structure used by EIGRP to store information about every known 329 destination including, but not limited to, network prefix/prefix length, 330 Feasible Distance, Reported Distance of each neighbor advertising the 331 destination, Computed Distance over the corresponding neighbor, and route state. 333 Type, Length, Value (TLV) 334 An encoding format for information elements used in EIGRP messages to 335 exchange information Each TLV-formatted information element consists of three 336 generic fields: Type identifying the nature of information carried in this 337 element; Length describing the length of the entire TLV triplet; and Value 338 carrying the actual information. The Value field may itself be internally 339 structured; this depends on the actual type of the information element. This 340 format allows for extensibility and backward compatibility. 342 Upstream Router 343 A router that is one or more hops away from the router in question, in the 344 direction of the source of the information. 346 Savage, et al. Expires August 16, 2015 [7] 347 3 The DUAL Diffusing Update Algorithm 348 The Diffusing Update Algorithm (DUAL) constructs least cost paths to all 349 reachable destinations in a network consisting of nodes and edges (routers and 350 links). DUAL guarantees that each constructed path is loop-free at every instant 351 including periods of topology changes and network re-convergence. This is 352 accomplished by all routers, which are affected by a topology change, computing 353 the new best path in a coordinated (diffusing) way and using the Feasibility 354 Condition to verify prospective paths for loop freedom. Routers that are not 355 affected by topology changes are not involved in the recalculation. The 356 convergence time with DUAL rivals that of any other existing routing protocol. 358 3.1 Algorithm Description 359 DUAL is used by EIGRP to achieve fast loop-free convergence with little 360 overhead, allowing EIGRP to provide convergence rates comparable, and in some 361 cases better than, most common link state protocols [8]. Only nodes that are 362 affected by a topology change need to propagate and act on information about the 363 topology change, allowing EIGRP to have good scaling properties, reduced 364 overhead, and lower complexity than many other interior gateway protocols. 366 Distributed routing algorithms are required to propagate information as well as 367 coordinate information among all nodes in the network. Unlike basic Bellman-Ford 368 distance vector protocols that rely on uncoordinated updates when a topology 369 change occurs, DUAL uses a coordinated procedure to involve the affected part of 370 the network into computing a new least cost path, known as a diffusing 371 computation. 372 A diffusing computation grows by querying additional routers for their current 373 Reported Distance to the affected destination, and shrinks by receiving replies 374 from them. Unaffected routers send replies immediately, terminating the growth 375 of the diffusing computation over them. These intrinsic properties cause the 376 diffusing computation to self-adjust in scope and terminate as soon as possible. 378 One attribute of DUAL is its ability to control the point at which the diffusion 379 of a route calculation terminates by managing the distribution of reachability 380 information through the network. Controlling the scope of the diffusing process 381 is accomplished by hiding reachability information through aggregation 382 (summarization), filtering, or other means. This provides the ability to create 383 effective failure domains within a single AS, and allows the network 384 administrator to manage the convergence and processing characteristics of the 385 network. 387 3.2 Route States 388 A route to a destination can be in one of two states, PASSIVE or ACTIVE. These 389 states describe whether the route is guaranteed to be both loop-free and the 390 shortest available (the PASSIVE state), or whether such guarantee cannot be 391 given (the ACTIVE state). Consequently, in PASSIVE state, the router does not 392 perform any route recalculation in coordination with its neighbors because no 393 such recalculation is needed. 395 In ACTIVE state, the router is actively involved in re-computing the least cost 396 loop-free path in coordination with its neighbors. The state is reevaluated and 397 possibly changed every time a topology change is detected. A topology change is 398 any event that causes the Computed Distance to the destination over any neighbor 399 to be added, changed, or removed from EIGRP's topology table. 401 Savage, et al. Expires August 16, 2015 [8] 402 More exactly, the two states are defined as follows: 404 o Passive 405 A route is considered in the Passive state when at least one neighbor that 406 provides the current least total cost path passes the Feasibility Condition 407 check that guarantees loop freedom. A route in the PASSIVE is usable and its 408 next hop is perceived to be a downstream router. 410 o Active 411 A route is considered in the ACTIVE state if neighbors that do not pass the 412 Feasibility Condition check provide lowest cost path, and therefore the path 413 cannot be guaranteed loop free. A route in the ACTIVE state is considered 414 unusable and this router must coordinate with its neighbors in the search for 415 the new loop-free least total cost path. 417 In other words, for a route to be in PASSIVE state, at least one neighbor that 418 provides the least total cost path must be a Feasible Successor. Feasible 419 Successors providing the least total cost path are also called Successors. For a 420 route to be in PASSIVE state, at least one Successor must exist. 422 Conversely, if the path with the least total cost is provided by routers that 423 are not Feasible Successors (and thus not Successors), the route is in the 424 ACTIVE state, requiring re-computation. 426 Notably, for the definition of PASSIVE and ACTIVE states it does not matter if 427 there are Feasible Successors providing a worse-than-least total cost path. 428 While these neighbors are guaranteed to provide a loop free path, that path is 429 potentially not the shortest available. 431 The fact that the least total cost path can be provided by a neighbor that fails 432 the Feasibility Condition check may not be intuitive. However, such situation 433 can occur during topology changes when the current least total cost path fails, 434 and the next least total cost path traverses a neighbor that is not a Feasible 435 Successor. 437 While a router has a route in the ACTIVE state, it must not change its Successor 438 (i.e. modify the current SDAG), nor modify its own Feasible Distance or Reported 439 Distance until the route enters the PASSIVE state again. Any updated information 440 about this route received during ACTIVE state is reflected only in Computed 441 Distances. Any updates to the Successor, Feasible Distance and Reported Distance 442 are postponed until the route returns to PASSIVE state. The state transitions 443 from PASSIVE to ACTIVE and from ACTIVE to PASSIVE are controlled by the DUAL FSM 444 and are described in detail in Section 3.5. 446 3.3 Feasibility Condition 447 The Feasibility Condition is a criterion used to verify loop freedom of a 448 particular path. The Feasibility Condition is a sufficient but not a necessary 449 condition, meaning that every path meeting the Feasibility Condition is 450 guaranteed to be loop-free; however, not all loop-free paths meet the 451 Feasibility condition. 452 The Feasibility Condition is used as an integral part of DUAL operation: Every 453 path selection in DUAL is subject to the Feasibility Condition check. Based on 454 the result of the Feasibility Condition check after a topology change is 455 detected, the route may either remain PASSIVE (if, after the topology change, 456 the neighbor providing the least cost path meets the Feasibility Condition) or 457 it needs to enter the ACTIVE state (if the topology change resulted in none of 458 the neighbors providing the least cost path to meet the Feasibility Condition). 460 Savage, et al. Expires August 16, 2015 [9] 461 The Feasibility Condition is a part of DUAL that allows the diffused computation 462 to terminate as early as possible. Nodes that are not affected by the topology 463 change are not required to perform a DUAL computation and may not be aware a 464 topology change occurred. This can occur in two cases; 466 First, if informed about a topology change, a router may keep a route in PASSIVE 467 State if it is aware of other paths that are downstream towards the destination 468 (routes meeting the Feasibility Condition). A route that meets the Feasibility 469 Condition is determined to be loop-free and downstream along the path between 470 the router and the destination. 472 Second, if informed about a topology change for which it does not currently have 473 reachability information, a router is not required to enter into the ACTIVE 474 state, nor is it required to participate in the DUAL process. 476 In order to facilitate describing the Feasibility Condition, a few definitions 477 are in order. 479 o A Successor for a given route is the next-hop used to forward data traffic 480 for a destination. Typically the successor is chosen based on the least cost 481 path to reach the destination. 483 o A Feasible Successor is a neighbor that meets the Feasibility Condition. A 484 Feasible Successor is regarded as a downstream neighbor towards the destination 485 but it may not be the least cost path, but could still be used for forwarding 486 data packets in the event equal or unequal cost load sharing was active. A 487 Feasible Successor can become a successor when the current successor becomes 488 unreachable. 490 o The Feasibility Condition is met when a neighbor's advertised cost, (RD) 491 to a destination is less than the Feasible Distance for that destination, or in 492 other words, the Feasibility Condition is met when the neighbor is closer to the 493 destination than the router itself has ever been since the destination has 494 entered the PASSIVE state for the last time. 496 o The Feasible Distance is the lowest distance to the destination since the 497 last time the route went from ACTIVE to PASSIVE state. It should be noted it is 498 not necessarily the current best distance - rather, it is a historical record of 499 the best distance known since the last diffusing computation for the destination 500 has finished. Thus, the value of the Feasible Distance can either be the same as 501 the current best distance, or it can be lower. 503 A neighbor that advertises a route with a cost that does not meet the 504 Feasibility Condition may be upstream and thus cannot be guaranteed to be the 505 next hop for a loop free path. Routes advertised by upstream neighbors are not 506 recorded in the routing table but saved in the topology table. 508 Savage, et al. Expires August 16, 2015 [10] 509 3.4 DUAL Message Types 510 The DUAL algorithm operates with three basic message types, QUERY, UPDATE, and 511 REPLY: 513 o UPDATE - sent to indicate a change in metric or an addition of a 514 destination. 516 o QUERY - sent when Feasibility Condition fails which can happen for reasons 517 like a destination becoming unreachable, or the metric increasing to a value 518 greater than its current Feasible Distance. 520 o REPLY - sent in response to a QUERY or SIA-QUERY 522 In addition to these 3 basic types, two addition sub-types have been added to 523 EIGRP: 525 o SIA-QUERY - sent when a REPLY has not been received within one half the 526 SIA interval (90 seconds as implemented by Cisco) 528 o SIA-REPLY - sent in response to an SIA-QUERY indicating the route is still 529 in ACTIVE state. This response does not stratify the original QUERY, but is 530 only used to indicate the sending neighbor is still in the ACTIVE State for the 531 given destination. 533 When in the PASSIVE State, a received QUERY may be propagated if there is no 534 Feasible Successor found. If a Feasible Successor is found, the QUERY is not 535 propagated and a REPLY is sent for the destination with a metric equal to the 536 current routing table metric. When a QUERY is received from a non-successor in 537 ACTIVE State a REPLY is sent and the QUERY is not propagated. The REPLY for the 538 destination contains a metric equal to the current routing table metric. 540 3.5 DUAL Finite State Machine (FSM) 541 The DUAL finite state machine embodies the decision process for all route 542 computations. It tracks all routes advertised by all neighbors. The distance 543 information, known as a metric, is used by DUAL to select efficient loop free 544 paths. DUAL selects routes to be inserted into a routing table based on Feasible 545 Successors. A successor is a neighboring router used for packet forwarding that 546 has least cost path to a destination that is guaranteed not to be part of a 547 routing loop. 548 When there are no Feasible Successors but there are neighbors advertising the 549 destination, a recalculation must occur to determine a new successor. 551 The amount of time it takes to calculate the route impacts the convergence time. 552 Even though the recalculation is not processor-intensive, it is advantageous to 553 avoid recalculation if it is not necessary. When a topology change occurs, DUAL 554 will test for Feasible Successors. If there are Feasible Successors, it will use 555 any it finds in order to avoid any unnecessary recalculation. 557 The finite state machine, which applies per destination in the topology table, 558 operates independently for each destination. It is true that if a single link 559 goes down, multiple routes may go into ACTIVE State. However, a separate 560 Successor Directed Acyclic Graph (SDAG) is computed for each destination, so 561 loop-free topologies can be maintained for each reachable destination. 563 Savage, et al. Expires August 16, 2015 [11] 564 Figure 1 illustrates the FSM: 566 i Node that is computing route. 567 j Destination node or network. 568 K Any neighbor of node i. 569 oij QUERY origin flag 570 0 = metric increase during ACTIVE State 571 1 = node i originated 572 2 = QUERY from, or link increase to, successor during ACTIVE State 573 3 = QUERY originated from successor. 574 rijk REPLY status flag for each neighbor k for destination j, 575 1 = awaiting REPLY, 576 0 = received REPLY. 577 lik = the link connecting node i to neighbor k. 579 +------------+ +-----------+ 580 | \ / | 581 | \ / | 582 | +=================================+ | 583 | | | | 584 |(1)| Passive |(2)| 585 +-->| |<--+ 586 +=================================+ 587 ^ | ^ ^ ^ | 588 (14)| |(15)| |(13)| | 589 | (4)| |(16)| | (3)| 590 | | | | | +------------+ 591 | | | | | \ 592 +-------+ + + | +-------------+ \ 593 / / / | \ \ 594 / / / +----+ \ \ 595 | | | | | | 596 | v | | | v 597 +==========+(11) +==========+ +==========+(12) +==========+ 598 | Active |---->| Active |(5) | Active |---->| Active | 599 | | (9)| |---->| | (10)| | 600 | Oij=0 |<----| Oij=1 | | Oij=2 |<----| Oij=3 | 601 +--| | +--| | +--| | +--| | 602 | +==========+ | +==========+ | +==========+ | +==========+ 603 | ^ |(5) | ^ | ^ ^ | ^ 604 | | +-----|------|---------|----+ | | | 605 +------+ +------+ +---------+ +---------+ 606 (6,7,8) (6,7,8) (6,7,8) (6,7,8) 608 Figure 1 - DUAL Finite State Machine 610 Savage, et al. Expires August 16, 2015 [12] 611 The following describes in detail the state/event/action transitions of the DUAL 612 FSM. For all steps, the topology table is updated with the new metric 613 information from either; QUERY, REPLY, or UPDATE received. 615 (1) A QUERY is received from a neighbor that is not the current successor. The 616 route is currently in Passive State. As the Successor is not affected by the 617 QUERY, and a Feasible Successor exists, the route remains in PASSIVE State. 618 Since a Feasible Successor exists, a REPLY MUST be sent back to the originator 619 of the QUERY. Any metric received in the QUERY from that neighbor is recorded in 620 the topology table and FC is run to check for any change to current successor. 622 (2) A directly connected interface changes state (connects, disconnects, or 623 changes metric), or similarly an UPDATE or QUERY has been received with a metric 624 change for an existing destination, the route will stay in the Active State if 625 the current successor is not affected by the change, or it is no longer 626 reachable and there is a Feasible Successor. In either case, an UPDATE is sent 627 with the new metric information if it has changed. 629 (3) A QUERY was received from a neighbor who is the current successor and no 630 Feasible Successors exist. The route for the destination goes into ACTIVE State. 631 A QUERY is sent to all neighbors on all interfaces that are not split horizon. 632 Split horizon takes effect for a query 633 or update from the successor it is using for the destination in the 634 query. The QUERY origin flag is set to indicate the QUERY originated from a 635 neighbor marked as successor for route. The REPLY status flag is set for all 636 neighbors to indicate outstanding replies. 638 (4) A directly connected link has gone down or its cost has increased, or an 639 UPDATE has been received with a metric increase. The route to the destination 640 goes to ACTIVE State if there are no Feasible Successors found. A QUERY is sent 641 to all neighbors on all interfaces. The QUERY origin flag is to indicate that 642 the router originated the QUERY. The REPLY status flag is set to 1 for all 643 neighbors to indicate outstanding replies. 645 (5) While a route for a destination is in ACTIVE State, and a QUERY is received 646 from the current successor, the route remains active. The QUERY origin flag is 647 set to indicate that there was another topology change while in ACTIVE State. 648 This indication is used so new Feasible Successors are compared to the metric 649 which made the route go to ACTIVE State with the current successor. 651 (6) While a route for a destination is in ACTIVE State and a QUERY is received 652 from a neighbor that is not the current successor, a REPLY should be sent to the 653 neighbor. The metric received in the QUERY should be recorded. 655 (7) If a link cost changes, or an UPDATE with a metric change is received in 656 ACTIVE State from a non-successor, the router stays in ACTIVE State for the 657 destination. The metric information in the UPDATE is recorded. When a route is 658 in the ACTIVE State, neither a QUERY nor UPDATE are ever sent. 660 (8) If a REPLY for a destination, in ACTIVE State, is received from a neighbor 661 or the link between a router and the neighbor fails, the router records that the 662 neighbor replied to the QUERY. The REPLY status flag is set to 0 to indicate 663 this. The route stays in ACTIVE State if there are more replies pending because 664 the router has not heard from all neighbors. 666 (9) If a route for a destination is in ACTIVE State, and a link fails or a cost 667 increase occurred between a router and its successor, the router treats this 668 case like it has received a REPLY from its successor. When this occurs after the 669 router originates a QUERY, it sets QUERY origin flag to indicate that another 671 Savage, et al. Expires August 16, 2015 [13] 672 topology change occurred in ACTIVE State. 674 (10) If a route for a destination is in ACTIVE State, and a link fails or a cost 675 increase occurred between a router and its successor, the router treats this 676 case like it has received a REPLY from its successor. When this occurs after a 677 successor originated a QUERY, the router sets the QUERY origin flag to indicate 678 that another topology change occurred in ACTIVE State. 680 (11) If a route for a destination is in ACTIVE State, the cost of the link 681 through which the successor increases, and the last REPLY was received from all 682 neighbors, but there is no Feasible Successor, the route should stay in ACTIVE 683 State. A QUERY is sent to all neighbors. The QUERY origin flag is set to 1. 685 (12) If a route for a destination is in ACTIVE State because of a QUERY received 686 from the current successor, and the last REPLY was received from all neighbors, 687 but there is no Feasible Successor, the route should stay in ACTIVE State. A 688 QUERY is sent to all neighbors. The QUERY origin flag is set to 3. 690 (13) Received replies from all neighbors. Since the QUERY origin flag indicates 691 the successor originated the QUERY, it transitions to PASSIVE State and sends a 692 REPLY to the old successor. 694 (14) Received replies from all neighbors. Since the QUERY origin flag indicates 695 a topology change to the successor while in ACTIVE State, it need not send a 696 REPLY to the old successor. When the Feasibility Condition is met, the route 697 state transitions to passive. 699 (15) Received replies from all neighbors. Since the QUERY origin flag indicates 700 either the router itself originated the QUERY or FC was not satisfied with the 701 replies received in ACTIVE state, FD is reset to infinite value and the minimum 702 of all the reported metrics is chosen as FD and route transitions back to 703 PASSIVE state. A REPLY is sent to the old-successor if Oij flags indicate that 704 there was a QUERY from successor. 706 (16) If a route for a destination is in ACTIVE State because of a QUERY received 707 from the current successor or there was an increase in Distance while in ACTIVE 708 state, the last REPLY was received from all neighbors, and a Feasible Successor 709 exists for the destination, the route can go into PASSIVE State and a REPLY is 710 sent to successor if Oij indicates that QUERY was received from successor. 712 Savage, et al. Expires August 16, 2015 [14] 713 3.6 DUAL Operation - Example Topology 714 The following topology (Figure 2) will be used to provide an example of how DUAL 715 is used to reroute after a link failure. Each node is labeled with its costs to 716 destination N. The arrows indicate the successor (next-hop) used to reach 717 destination N. The least cost path is selected. 719 N 720 | 721 (1)A ---<--- B(2) 722 | | 723 ^ | 724 | | 725 (2)D ---<--- C(3) 727 Figure 2 - Stable Topology 729 In the case where the link between A and D fails (Figure 3); 731 N N 732 | | 733 A ---<--- B A ---<--- B 734 | | | | 735 X | ^ | 736 | | | | 737 D ---<--- C D ---<--- C 738 Q-> <-R 739 N 740 | 741 (1)A ---<--- B(2) 742 | 743 ^ 744 | 745 (4)D --->--- C(3) 747 Figure 3 - Link between A and D fails 749 Only observing destination provided by node N, D enters the ACTIVE State and 750 sends a QUERY to all its neighbors, in this case node C. 751 C determines that it has a Feasible Successor and replies immediately with 752 metric 3. 753 C changes its old successor of D to its new single successor B and the route 754 to N stays in PASSIVE State. 755 D receives the REPLY and can transition out of ACTIVE State since it received 756 replies from all its neighbors. 757 D now has a viable path to N through C. 758 D elects C as its successor to reach node N with a cost of 4. 760 Notice that node A and B were not involved in the recalculation since they were 761 not affected by the change. 763 Let s consider the situation in Figure 4, where Feasible Successors may not 764 exist. If the link between node A and B fails, B goes into ACTIVE State for 765 destination N since it has no Feasible Successors. 766 Node B sends a QUERY to node C. C has no Feasible Successors, so it goes active 767 for destination N and sends QUERY to B. B replies to the QUERY since it is in 768 ACTIVE State. 770 Savage, et al. Expires August 16, 2015 [15] 771 Once C has received this REPLY, it has heard from all its neighbors, so it can 772 go passive for the unreachable route. As C removes the (now unreachable) 773 destination from its table, C sends REPLY to its old successor. B receives this 774 REPLY from C, and determines this is the last REPLY it is waiting on before 775 determining what the new state of the route should be; on receiving this REPLY, 776 B deletes the route to N from its routing table. 778 Since B was the originator of the initial QUERY it does not have to send a REPLY 779 to its old successor (it would not be able to any ways, because the link to its 780 old successor is down). Note that nodes A and D were not involved in the 781 recalculation since their successors were not affected. 783 N N 784 | | 785 (1)A ---<--- B(2) A ------- B Q 786 | | | | |^ ^ 787 ^ ^ ^ | v| | 788 | | | | | | 789 (2)D C(3) D C ACK R 791 Figure 4 792 No Feasible Successors when link between A and B fails 794 Savage, et al. Expires August 16, 2015 [16] 795 4 EIGRP Packets 796 EIGRP uses 5 different packet types to handle session management and pass DUAL 797 Message types: 799 HELLO Packets (includes ACK) 800 QUERY Packets (includes SIA-Query) 801 REPLY Packets (includes SIA-Reply) 802 REQUEST Packets 803 UPDATE Packets 805 EIGRP packets are directly encapsulated into a network layer protocol, such as 806 IPv4 or IPv6. While EIGRP is capable of using additional encapsulation (such as 807 AppleTalk, IPX, etc) no further encapsulation is specified in this draft. 809 Support for network layer protocol fragmentation is not supported, and EIGRP 810 will attempt to avoid a maximum size packets that exceed the interface MTU by 811 sending multiple packets which are less than or equal to MTU sized packets. 813 Each packet transmitted will use either multicast or unicast network layer 814 destination addresses. When multicast addresses are used a mapping for the data 815 link multicast address (when available) must be provided. The source address 816 will be set to the address of the sending interface, if applicable. The 817 following network layer multicast addresses and associated data link multicast 818 addresses will be used. 820 IPv4 - 224.0.0.10 821 IPv6 - FF02:0:0:0:0:0:0:A 823 The above data link multicast addresses will be used on multicast capable media, 824 and will be media independent for unicast addresses. Network layer addresses 825 will be used and the mapping to media addresses will be achieved by the native 826 protocol mechanisms. 828 4.1 UPDATE Packets 829 UPDATE packets carry the DUAL UPDATE message type, and are used to convey 830 information about destinations and the reachability of those destinations. When 831 a new neighbor is discovered, unicast UPDATE packets are used to transmit a full 832 table to the new neighbor, so the neighbor can build up its topology table. In 833 normal operation (other than neighbor startup such as a link cost changes), 834 UPDATE packets are multicast. UPDATE packets are always transmitted reliably. 835 Each TLV destination will be processed individually through the DUAL state 836 machine. 838 4.2 QUERY Packets 839 A QUERY packet carries the DUAL QUERY message type and is sent by a router to 840 advertise that a route is in ACTIVE State and the originator is requesting 841 alternate path information from its neighbors. An infinite metric is encoded by 842 setting the Delay part of the metric to its maximum value. 844 If there is a topology change that causes multiple destinations to be marked 845 ACTIVE, EIGRP will build a single QUERY packet with all destinations present. 846 The state of each route is recorded individually, so a responding QUERY or REPLY 847 need not contain all the same destinations in a single packet. Since EIGRP uses 848 a reliable transport mechanism, route QUERY packets are also guaranteed be 849 reliably delivered. 851 When a QUERY packet is received, each destination will trigger a DUAL event and 853 Savage, et al. Expires August 16, 2015 [17] 854 the state machine will run individually for each route. Once the entire original 855 QUERY packet is processed, then a REPLY or SIA-REPLY will be sent with the 856 latest information. 858 4.3 REPLY Packets 859 A REPLY packet carries the DUAL REPLY message type and will be sent in response 860 to a QUERY or SIA-QUERY packet. The REPLY packet will include a TLV for each 861 destination and the associated vector metric in its own topology table. 863 The REPLY packet is sent after the entire received QUERY packet is processed. 864 When a REPLY packet is received, there is no reason to process the packet before 865 an acknowledgment is sent. Therefore, an acknowledgment is sent immediately and 866 then the packet is processed. The sending of the acknowledgement is accomplished 867 either by sending an ACK packet, or piggybacked the acknowledgment onto another 868 packet already being transmitted. 870 Each TLV destination will be processed individually through the DUAL state 871 machine. When a QUERY is received for a route that doesn t exist in our topology 872 table, a REPLY with infinite metric is sent and an entry in the topology table 873 is added with the metric in the QUERY if the metric is not an infinite value. 875 4.4 Exception Handling 877 4.4.1 Active Duration (Stuck-in-Active) 878 When an EIGRP router transitions to ACTIVE state for a particular destination a 879 QUERY is sent to a neighbor and the ACTIVE timer is started to limit the amount 880 of time a destination may remain in an ACTIVE State. 882 A route is regarded as Stuck-In-Active (SIA) when it does not receive a REPLY 883 within a preset time. This time interval is broken into two equal periods 884 following the QUERY, and up to 3 additional busy periods in which an SIA-QUERY 885 packet is sent for the destination. 887 This process is begun when a router sends a QUERY to its neighbor. After one 888 half the SIA time interval (default implementation is 90 seconds), the router 889 will send an SIA-QUERY; this must be replied to with either a REPLY or SIA- 890 REPLY. Any neighbor which fails to send either a REPLY or SIA-REPLY with-in one- 891 half the SIA interval will result in the neighbor being deemed to be stuck in 892 the active state. 894 If the SIA state is declared, DUAL may take one of two actions; 895 a) Delete the route from that neighbor, acting as if the neighbor had 896 responded with an unreachable REPLY message from the neighbor. 898 b) Delete all routes from that neighbor and reset the adjacency with that 899 neighbor, acting as if the neighbor had responded with an unreachable message 900 for all routes. 902 Implementation note: Cisco currently implements option B. 904 4.4.1.1 SIA-QUERY 905 When a QUERY is still outstanding and awaiting a REPLY from a neighbor, there is 906 insufficient information to determine why a REPLY has not been received. A lost 907 packet, congestion on the link, or a slow neighbor could cause a lack of REPLY 908 from a downstream neighbor. 910 In order to attempt to ascertain if the neighboring device is still attempting 912 Savage, et al. Expires August 16, 2015 [18] 913 to converge on the active route, EIGRP may send an SIA-QUERY packet to the 914 active neighbor(s). This enables an EIGRP router to determine if there is a 915 communication issue with the neighbor, or it is simply still attempting to 916 converge with downstream routers. 918 By sending an SIA-QUERY, the originating router may extend the effective active 919 time by resetting the ACTIVE timer which has been previously set, thus allowing 920 convergence to continue so long as neighbor devices successfully communicate 921 that convergence is still underway. 923 The SIA-QUERY packet SHOULD be sent on a per-destination basis at one-half of 924 the ACTIVE timeout period. Up to three SIA-QUERY packets for a specific 925 destination may be sent, each at a value of one-half the ACTIVE time, so long as 926 each are successfully acknowledged and met with an SIA-REPLY. 928 Upon receipt of an SIA-QUERY packet, and EIGRP router should first send an ACK 929 and then continue to process the SIA-QUERY information. The QUERY is sent on a 930 per-destination basis at approximately one-half the active time. 932 If the EIGRP router is still active for the destination specified in the SIA- 933 QUERY, the router should respond to the originator with the SIA-REPLY indicating 934 that active processing for this destination is still underway by setting the 935 ACTIVE flag in the packet upon response. 937 If the router receives an SIA-QUERY referencing a destination for which it has 938 not received the original QUERY, the router should treat the packet as though it 939 was a standard QUERY: 941 1) Acknowledge the receipt of the packet 942 2) Send a REPLY if a Successor exists 943 3) If the QUERY is from the successor, transition to the ACTIVE state if and 944 only if feasibility-condition fails and send an SIA-REPLY with the ACTIVE bit 945 set 947 4.4.1.2 SIA-REPLY 948 An SIA-REPLY packet is the corresponding response upon receipt of an SIA-QUERY 949 from an EIGRP neighbor. The SIA-REPLY packet will include a TLV for each 950 destination and the associated metric for which is stored in its own routing 951 table. The SIA-REPLY packet is sent after the entire received SIA-QUERY packet 952 is processed. 954 If the EIGRP router is still ACTIVE for a destination, the SIA-REPLY packet will 955 be sent with the ACTIVE bit set. This confirms for the neighbor device that the 956 SIA-QUERY packet has been processed by DUAL and that the router is still 957 attempting to resolve a loop-free path (likely awaiting responses to its own 958 QUERY to downstream neighbors). 960 The SIA-REPLY informs the recipient that convergence is complete or still 961 ongoing, however; it is an explicit notification that the router is still 962 actively engaged in the convergence process. This allows the device that sent 963 the SIA-QUERY to determine whether it should continue to allow the routes that 964 are not converged to be in the ACTIVE state, or if it should reset the neighbor 965 relationship and flush all routes through this neighbor. 967 Savage, et al. Expires August 16, 2015 [19] 968 5 EIGRP Protocol Operation 969 EIGRP has four basic components: 970 o Finite State Machine 971 o Reliable Transport Protocol 972 o Neighbor Discovery/Recovery 973 o Route Management 975 5.1 Finite State Machine 976 The detail of DUAL, the State Machine used by EIGRP, is covered in Section 3 978 5.2 Reliable Transport Protocol 979 The reliable transport is responsible for guaranteed, ordered delivery of EIGRP 980 packets to all neighbors. It supports intermixed transmission of multicast or 981 unicast packets. Some EIGRP packets must be transmitted reliably and others need 982 not. For efficiency, reliability is provided only when necessary. 984 For example, on a multi-access network that has multicast capabilities, such as 985 Ethernet, it is not necessary to send HELLOs reliably to all neighbors 986 individually. EIGRP sends a single multicast HELLO with an indication in the 987 packet informing the receivers that the packet need not be acknowledged. Other 988 types of packets, such as UPDATE packets, require acknowledgment and this is 989 indicated in the packet. The reliable transport has a provision to send 990 multicast packets quickly when there are unacknowledged packets pending. This 991 helps insure that convergence time remains low in the presence of varying speed 992 links. 994 The DUAL Algorithm assumes there is lossless communication between devices and 995 thus must rely upon the transport protocol to guarantee that messages are 996 transmitted reliably. EIGRP implements the Reliable Transport Protocol to ensure 997 ordered delivery and acknowledgement of any messages requiring reliable 998 transmission. State variables such as a received sequence number, acknowledgment 999 number, and transmission queues MUST be maintained on a per neighbor basis. 1001 The following sequence number rules must be met for the reliable EIGRP protocol 1002 to work correctly: 1004 o A sender of a packet includes its global sequence number 1005 in the sequence number field of the fixed header. The 1006 sender includes the receivers sequence number in the 1007 acknowledgment number field of the fixed header. 1008 o Any packets that do not require acknowledgment must be 1009 sent with a sequence number of 0. 1010 o Any packet that has an acknowledgment number of zero (0) 1011 indicates that sender is not expecting to explicitly 1012 acknowledging delivery. Otherwise, it is acknowledging 1013 a single packet. 1014 o Packets that are network layer multicast must contain 1015 acknowledgment number of 0. 1017 When a router transmits a packet, it increments its sequence number and marks 1018 the packet as requiring acknowledgment by all neighbors on the interface for 1019 which the packet is sent. When individual acknowledgments are unicast addressed 1020 by the receivers to the sender with the acknowledgment number equal to the 1021 packets sequence number, the sender SHALL clear the pending acknowledgement 1022 requirement for the packet from the respective neighbor. 1024 Savage, et al. Expires August 16, 2015 [20] 1025 If the required acknowledgement is not received for the packet, it MUST be 1026 retransmitted. Retransmissions will occur for a maximum of 5 seconds. This 1027 retransmission for each packet is tried 16 times after which if there is no ACK, 1028 the neighbor relationship is reset with that peer which didn t send the ACK. 1030 The protocol has no explicit windowing support. A receiver will acknowledge each 1031 packet individually and will drop packets that are received out of order. 1032 Duplicate packets are also discarded upon receipt. Acknowledgments are not 1033 accumulative. Therefore an ACK with a non-zero sequence number acknowledges a 1034 single packet. 1036 There are situations when multicast and unicast packets are transmitted close 1037 together on multi-access broadcast capable networks. The reliable transport 1038 mechanism MUST assure that all multicasts are transmitted in order as well as 1039 not mixing the order among unicasts and multicast packets. The reliable 1040 transport provides a mechanism to deliver multicast packets in order to some 1041 receivers quickly, while some receivers have not yet received all unicast or 1042 previously sent multicast packets. The SEQUENCE_TYPE TLV in HELLO packets 1043 achieves this. This will be explained in more detail in this section. 1045 Figure 5 illustrates the reliable transport protocol on point-to-point links. 1046 There are two scenarios that may occur, an UPDATE initiated packet exchange, or 1047 a QUERY initiated packet exchange. 1049 This example will assume no packet loss. 1051 Router A Router B 1052 An UPDATE Exchange 1053 <---------------- 1054 UPDATE (multicast) 1055 A receives packet SEQ=100, ACK=0 1056 Queues pkt on A s retransmit list 1057 ----------------> 1058 ACK (unicast) 1059 SEQ=0, ACK=100 Receives ACK 1060 Process UPDATE Dequeue pkt from A s retransmit list 1062 A QUERY Exchange 1063 <---------------- 1064 QUERY (multicast) 1065 A receives packet SEQ=101, ACK=0 1066 Process QUERY Queues pkt on A s retransmit list 1068 ----------------> 1069 REPLY (unicast) 1070 SEQ=201, ACK=101 Process ACK 1071 Dequeue pkt from A s retransmit list 1072 Process REPLY pkt 1073 <---------------- 1074 ACK (unicast) 1075 A receives packet SEQ=0, ACK=201 1077 Figure 5 - Reliable Transfer on point-to-point links 1079 Savage, et al. Expires August 16, 2015 [21] 1080 The UPDATE exchange sequence requires UPDATE packets sent to be delivered 1081 reliably. The UPDATE packet transmitted contains a sequence number that is 1082 acknowledged by a receipt of an ACK packet. If the UPDATE or the ACK packet is 1083 lost on the network, the UPDATE packet will be retransmitted. 1085 Figure 6 illustrates the situation where there is heavy packet loss on a 1086 network. 1088 Router A Router B 1089 <---------------- 1090 UPDATE (multicast) 1091 A receives packet SEQ=100, ACK=0 1092 Queues pkt on A s retransmit list 1093 ----------------> 1094 ACK (unicast) 1095 SEQ=0, ACK=100 Receives ACK 1096 Process Update Dequeue pkt from A s retransmit list 1098 <--/LOST/-------------- 1099 UPDATE (multicast) 1100 SEQ=101, ACK=0 1101 Queues pkt on A s retransmit list 1103 Retransmit Timer Expires 1104 <---------------- 1105 Retransmit UPDATE (unicast) 1106 SEQ=101, ACK=0 1107 Keeps pkt on A s retransmit list 1108 ----------------> 1109 ACK (unicast) 1110 SEQ=0, ACK=101 Receives ACK 1111 Process Update Dequeue pkt from A s retransmit list 1113 Figure 6 1114 Reliable Transfer on lossy point-to-point links 1116 Savage, et al. Expires August 16, 2015 [22] 1117 Reliable delivery on multi-access LANs works in a similar fashion to point-to- 1118 point links. The initial packet is always multicast and subsequent 1119 retransmissions are unicast addressed. The acknowledgments sent are always 1120 unicast addressed. Figure 7 shows an example with 4 routers on an Ethernet. 1122 Router B -----------+ 1123 | 1124 Router C -----------+------------ Router A 1125 | 1126 Router D -----------+ 1128 An UPDATE Exchange 1129 <---------------- 1130 A send UPDATE (multicast) 1131 SEQ=100, ACK=0 1132 Queues pkt on B s retransmit list 1133 Queues pkt on C s retransmit list 1134 Queues pkt on D s retransmit list 1135 ----------------> 1136 B sends ACK (unicast) 1137 SEQ=0, ACK=100 Receives ACK 1138 Process Update Dequeue pkt from B s retransmit list 1140 ----------------> 1141 C sends ACK (unicast) 1142 SEQ=0, ACK=100 Receives ACK 1143 Process Update Dequeue pkt from C s retransmit list 1145 ----------------> 1146 D sends ACK (unicast) 1147 SEQ=0, ACK=100 Receives ACK 1148 Process Update Dequeue pkt from D s retransmit list 1150 A QUERY Exchange 1151 <---------------- 1152 A send UPDATE (multicast) 1153 SEQ=101, ACK=0 1154 Queues pkt on B s retransmit list 1155 Queues pkt on C s retransmit list 1156 Queues pkt on D s retransmit list 1157 ----------------> 1158 B send REPLY (unicast) <---------------- 1159 SEQ=511, ACK=101 A sends ACK (unicast to B) 1160 Process Update SEQ=0, ACK=511 1161 Dequeue pkt from B s retransmit list 1162 ----------------> 1163 C send REPLY (unicast) <---------------- 1164 SEQ=200, ACK=101 A sends ACK (unicast to C) 1165 Process Update SEQ=0, ACK=200 1166 Dequeue pkt from C s retransmit list 1167 ----------------> 1168 D send REPLY (unicast) <---------------- 1169 SEQ=11, ACK=101 A sends ACK (unicast to D) 1170 Process Update SEQ=0, ACK=11 1171 Dequeue pkt from D s retransmit list 1173 Figure 7 1174 Reliable Transfer on Multi-Access Links 1176 Savage, et al. Expires August 16, 2015 [23] 1177 And finally, a situation where numerous multicast and unicast packets are sent 1178 close together in a multi-access environment is illustrated in Figure 9. 1180 Router B -----------+ 1181 | 1182 Router C -----------+------------ Router A 1183 | 1184 Router D -----------+ 1186 <---------------- 1187 A send UPDATE (multicast) 1188 SEQ=100, ACK=0 1189 ---------------/LOST/-> Queues pkt on B s retransmit list 1190 B send ACK (unicast) Queues pkt on C s retransmit list SEQ=0, 1191 ACK=100 Queues pkt on D s retransmit list 1193 ----------------> 1194 C sends ACK (unicast) 1195 SEQ=0, ACK=100 Dequeue pkt from C s retransmit list 1197 ----------------> 1198 D sends ACK (unicast) 1199 SEQ=0, ACK=100 Dequeue pkt from D s retransmit list 1200 <---------------- 1201 A send HELLO (multicast) 1202 SEQ=101, ACK=0, SEQ_TLV listing B 1204 B receives Hello, does not set CR-Mode 1205 C receives Hello, sets CR-Mode 1206 D receives Hello, sets CR-Mode 1207 <---------------- 1208 A send UPDATE (multicast) 1209 SEQ=101, ACK=0, CR-Flag=1 1210 ---------------/LOST/-> Queues pkt on B s retransmit list 1211 B send ACK (unicast) Queues pkt on C s retransmit list SEQ=0, 1212 ACK=100 Queues pkt on D s retransmit list 1214 B ignores UPDATE 101 because CR-Flag 1215 is set and it is not in CR-Mode 1217 ----------------> 1218 C sends ACK (unicast) 1219 SEQ=0, ACK=101 1221 ----------------> 1222 D sends ACK (unicast) 1223 SEQ=0, ACK=101 1224 <---------------- 1225 A resends UPDATE (unicast to B) 1226 SEQ=100, ACK=0 1227 B Packet duplicate 1228 ---------------> 1229 B sends ACK (unicast) A removes pkt from retransmit list 1230 SEQ=0, ACK=100 1231 <---------------- 1232 A resends UPDATE (unicast to B) 1233 SEQ=101, ACK=0 1234 ---------------> 1235 B sends ACK (unicast) A removes pkt from retransmit list 1236 SEQ=0, ACK=101 1238 Savage, et al. Expires August 16, 2015 [24] 1239 Figure 9 1241 Initially Router-A sends a multicast addressed UPDATE packet on the LAN. B and C 1242 receive it and send acknowledgments. Router-B receives the UPDATE but the 1243 acknowledgment sent is lost on the network. Before the retransmission timer for 1244 Router-B s packet expires, there is an event that causes a new multicast 1245 addressed UPDATE to be sent. 1247 Router-A detects that there is at least one neighbor on the interface with a 1248 full queue. Therefore, it MUST signal that neighbor to not receive the next 1249 packet or it would receive the retransmitted packet out of order. 1251 Router-A builds a HELLO packet with a SEQUENCE_TYPE TLV indicating all the 1252 neighbors that have full queues. In this case, the only neighbor address in the 1253 list is Router-B. The HELLO packet is sent via multicast unreliably out the 1254 interface. 1256 Router-C and Router-D process the SEQUENCE_TYPE TLV by looking for its own 1257 address in the list. If not found, they put themselves in Conditionally Received 1258 (CR-mode) mode. 1260 Router-B does not find its address in the SEQUENCE TLV peer list, so it enters 1261 CR-mode. Packets received by Router-B with the CR-flag MUST be discarded and not 1262 acknowledged. 1264 Later, Router-A will unicast transmit both packets 100 and 101 directly to 1265 Router-B. Router-B already has 100 so it discards and acknowledges it. 1267 Router-B then accepts and acknowledges packet 101. Once an acknowledgement is 1268 received, Router-A can remove both packets off Router-B s transmission list. 1270 5.2.1 Bandwidth on Low-Speed Links 1271 By default, EIGRP limits itself to using no more than 50% of the bandwidth 1272 reported by an interface when determining packet-pacing intervals. If the 1273 bandwidth does not match the physical bandwidth (the network architect may have 1274 put in an artificially low or high bandwidth value to influence routing 1275 decisions), EIGRP may: 1277 1. Generate more traffic than the interface can handle, possibly causing 1278 drops, thereby impairing EIGRP performance. 1280 2. Generate a lot of EIGRP traffic that could result in little bandwidth 1281 remaining for user data. To control such transmissions an interface-pacing timer 1282 is defined for the interfaces on which EIGRP is enabled. When a pacing timer 1283 expires, a packet is transmitted out on that interface. 1285 5.3 Neighbor Discovery/Recovery 1286 Neighbor Discovery/Recovery is the process that routers use to dynamically learn 1287 of other routers on their directly attached networks. Routers MUST also discover 1288 when their neighbors become unreachable or inoperative. This process is achieved 1289 with low overhead by periodically sending small HELLO packets. As long as any 1290 packets are received from a neighbor, the router can determine that neighbor is 1291 alive and functioning. Only after a neighbor router is considered operational 1292 can the neighboring routers exchange routing information. 1294 Savage, et al. Expires August 16, 2015 [25] 1295 5.3.1 Neighbor Hold Time 1296 Each router keeps state information about adjacent neighbors. When newly 1297 discovered neighbors are learned the address, interface, and hold time of the 1298 neighbor is noted. When a neighbor sends a HELLO, it advertises its Hold Time. 1299 The Hold Time is the amount of time a router treats a neighbor as reachable and 1300 operational. In addition to the HELLO packet, if any packet is received within 1301 the hold time period, then the Hold Time period will be rest. When the Hold Time 1302 expires, DUAL is informed of the topology change. 1304 5.3.2 HELLO Packets 1305 When an EIGRP router is initialized, it will start sending HELLO packets out any 1306 interface on which EIGRP is enabled. HELLO packets, when used for neighbor 1307 discovery, are normally sent multicast addressed. The HELLO packet will include 1308 the configured EIGRP metric K-values. Two routers become neighbors only if the 1309 K-values are the same. This enforces that the metric usage is consistent 1310 throughout the Internet. Also included in the HELLO packet, is a Hold Time 1311 value. This value indicates to all receivers the length of time in seconds that 1312 the neighbor is valid. The default Hold Time will be 3 times the HELLO interval. 1313 HELLO packets will be transmitted every 5 seconds (by default). There may be a 1314 configuration command that controls this value and therefore changes the Hold 1315 Time. HELLO packets are not transmitted reliably so the sequence number should 1316 be set to 0. 1318 5.3.3 UPDATE Packets 1319 When a router detects a new neighbor by receiving a HELLO packet from a neighbor 1320 not presently known, it will send a unicast UPDATE packet to the neighbor with 1321 no routing information. The initial UPDATE packet sent MUST have the INIT-flag 1322 set. This instructs the neighbor to advertise its routes. The INIT-flag is also 1323 useful when a neighbor goes down and comes back up before the router detects it 1324 went down. In this case, the neighbor needs new routing information. The INIT- 1325 flag informs the router to send it. 1327 5.3.3.1 NULL Update 1328 The number of destinations in its routing table will require at a minimum two 1329 (2) UPDATE packets to be sent. The first UPDATE packet (referred it as the NULL 1330 UPDATE packet) is sent with the INIT-Flag, and containing no topology 1331 information. The use of the NULL UPDATE is used to ensure di-directional UNICAST 1332 packet delivery. 1334 DVS: add more 1336 The second packet is queued, and cannot be sent until the first is acknowledged. 1338 5.3.4 Initialization Sequence 1339 Router A Router B 1340 (just booted) (up and running) 1342 (1)----------------> 1343 HELLO (multicast) <---------------- (2) 1344 SEQ=0, ACK=0 HELLO (multicast) 1345 SEQ=0, ACK=0 1347 <---------------- (3) 1348 UPDATE (unicast) 1349 SEQ=10, ACK=0, INIT 1350 (4)----------------> UPDATE 11 is queued 1351 UPDATE (unicast) 1353 Savage, et al. Expires August 16, 2015 [26] 1354 SEQ=100, ACK=10, INIT <---------------- (5) 1355 UPDATE (unicast) 1356 SEQ=11, ACK=100 1357 All UPDATES sent 1358 (6)--------------/lost/-> 1359 ACK (unicast) 1360 SEQ=0, ACK=11 1361 (5 seconds later) 1362 <---------------- (7) 1363 Duplicate received, UPDATE (unicast) 1364 Packet discarded SEQ=11, ACK=100 1365 (8)---------------> 1366 ACK (unicast) 1367 SEQ=0, ACK=11 1369 Figure 9 - Initialization Sequence 1371 (1) Router A sends multicast HELLO and Router B discovers it. 1373 (2) Router B sends an expedited HELLO and starts the process of sending its 1374 topology table to Router A. In addition, Router B sends the NULL UPDATE packet 1375 with the INIT-Flag. The second packet is queued, but cannot be sent until the 1376 first is acknowledged. 1378 (3) Router A receives first UPDATE packet and processes it as a DUAL event. If 1379 the UPDATE contains topology information, the packet will be process and stored 1380 in topology table. Sends its first and only UPDATE packet with an accompanied 1381 ACK. 1383 (4) Router B receives UPDATE packet 100 from Router A. Router B can dequeue 1384 packet 10 from A s transmission list since the UPDATE acknowledged 10. It can 1385 now send UPDATE packet 11 and with an acknowledgment of Router A s UPDATE. 1387 (5) Router A receives the last UPDATE packet from Router B and acknowledges it. 1388 The acknowledgment gets lost. 1390 (6) Router B later retransmits the UPDATE packet to Router A. 1392 (7) Router A detects the duplicate and simply acknowledges the packet. Router B 1393 dequeues packet 11 from A s transmission list and both routers are up and 1394 synchronized. 1396 5.3.5 Neighbor Formation 1397 To prevent packets from being sent to a neighbor prior to verifying multicast 1398 and unicast packet delivery is reliable, a 3-way handshake is utilized. 1400 During normal adjacency formation, multicast HELLOs cause the EIGRP process to 1401 place new neighbors into the neighbor table. Unicast packets are then used to 1402 exchange known routing information, and complete the neighbor relationship 1403 (section 5.2) 1405 To prevent EIGRP from sending sequenced packets to neighbor which fail to have 1406 bidirectional unicast/multicast, or one neighbor restarts while building the 1407 relationship, EIGRP MUST place the newly discovered neighbor in a pending 1408 state as follows: 1409 When Router-A receives the first multicast HELLO from Router-B, it places 1410 Router-B in the pending state, and transmits a unicast UPDATE containing no 1411 topology information and SHALL set the initialization bit. While Router-B is in 1412 this state, A will not send it any a QUERY or UPDATE. When Router-A receives the 1414 Savage, et al. Expires August 16, 2015 [27] 1415 unicast acknowledgement from Router-B, it will check the state from pending to 1416 up . 1418 5.3.6 QUERY Packets During Neighbor Formation 1419 As described above, during the initial formation of the neighbor relationship, 1420 EIGRP uses a form of three-way handshake to verify both unicast and multicast 1421 connectivity are working successfully. During this period of neighbor creation 1422 the new neighbor is considered to be the pending state, and is not eligible to 1423 be included in the convergence process. Because of this, any QUERY received by 1424 an EIGRP router would not cause a QUERY to be sent to the new (and pending) 1425 neighbor. It would perform the DUAL process without the new peer in the 1426 conversation. 1427 To do this, when a router in the process of establishing a new neighbor receives 1428 a QUERY from a fully established neighbor, it performs the normal DUAL Feasible 1429 Successor check to determine whether it needs to REPLY with a valid path or 1430 whether it needs to enter the ACTIVE process on the prefix. 1431 If it determines that it must go active, each fully established neighbor that 1432 participates in the convergence process will be sent a QUERY packet and REPLY 1433 packets are expected from each. Any pending neighbor will not be expected to 1434 REPLY and will not be sent a QUERY directly. If it resides on an interface 1435 containing a mix of fully established neighbors and pending neighbors, it might 1436 receive the QUERY but will not be expected to REPLY to it. 1438 5.4 Topology Table 1439 The Topology Table is populated by the protocol dependent modules (IPv4/IPv6 1440 PDM), and is acted upon by the DUAL finite state machine. Associated with each 1441 entry are the destination address and a list of neighbors that have advertised 1442 this destination, and the metric associated with the destination. The metric is 1443 referred to as the Computed Distance. 1445 The Computed Distance is the best-advertised Reported Distance from all 1446 neighbors, plus the link cost between the receiving router and the neighbor. 1448 The Reported Distance is the Computed Distance as advertised by the Feasible 1449 Successor for the destination. Said another way, the Computed distance, when 1450 sent by a neighbor, is referred to as the Reported Distance and is the metric 1451 that the neighboring router uses to reach the destination (Its Computed Distance 1452 as described above). 1454 If the router is advertising a destination route, it MUST be using the route to 1455 forward packets; this is an important rule that distance vector protocols MUST 1456 follow. 1458 5.4.7 Route Management 1459 Within the topology table, EIGRP has the notion of internal and external routes. 1460 Internal routes MUST be prefered over external routes independent of the metric. 1461 I practical terms, if and internal route is received, the Dufusion comoutation 1462 will be run considering only the interal routes. Only when no internal routes 1463 for a give destination exist, will EIGRP choose the a Successor from the 1464 available external routes. 1466 5.4.7.1 Internal Routes 1467 Internal routes are destinations that have been originated within the same EIGRP 1468 Autonomous System. Therefore, a directly attached network that is configured to 1469 run EIGRP is considered an internal route and is propagated with this 1470 information throughout the network topology. 1472 Savage, et al. Expires August 16, 2015 [28] 1473 Internal routes are tagged with the following information: 1474 o Router ID of the EIGRP router that originated the route. 1475 o Configurable administrator tag. 1477 5.4.7.2 External routes 1478 External routes are destinations that have been learned from another source, 1479 such as a different routing protocol or static route. These routes are marked 1480 individually with the identity of their origination. 1482 External routes are tagged with the following information: 1483 o Router ID of the EIGRP router that redistributed the route. 1484 o AS number where the destination resides. 1485 o Configurable administrator tag. 1486 o Protocol ID of the external protocol. 1487 o Metric from the external protocol. 1488 o Bit flags for default routing. 1490 As an example, suppose there is an AS with three border routers (BR1, BR2, and 1491 BR3). A border router is one that runs more than one routing protocol. The AS 1492 uses EIGRP as the routing protocol. Two of the border routers, BR1 and BR2, also 1493 use Open Shortest Path First (OSPF) and the other, BR3, also uses Routing 1494 Information Protocol (RIP). 1496 Routes learned by one of the OSPF border routers, BR1, can be conditionally 1497 redistributed into EIGRP. This means that EIGRP running in BR1 advertises the 1498 OSPF routes within its own AS. When it does so, it advertises the route and tags 1499 it as an OSPF learned route with a metric equal to the routing table metric of 1500 the OSPF route. The router-id is set to BR1. The EIGRP route propagates to the 1501 other border routers. 1503 Let's say that BR3, the RIP border router, also advertises the same destinations 1504 as BR1. Therefore BR3, redistributes the RIP routes into the EIGRP AS. BR2, 1505 then, has enough information to determine the AS entry point for the route, the 1506 original routing protocol used, and the metric. 1508 Further, the network administrator could assign tag values to specific 1509 destinations when redistributing the route. BR2 can use any of this information 1510 to use the route or re-advertise it back out into OSPF. 1512 Using EIGRP route tagging can give a network administrator flexible policy 1513 controls and help customize routing. Route tagging is particularly useful in 1514 transit AS s where EIGRP would typically interact with an inter-domain routing 1515 protocol that implements global policies. 1517 5.4.7.3 Split Horizon and Poison Reverse 1519 In some circumstances, EIGRP will suppress or poison QUERY and UPDATE 1520 information to prevent routing loops as changes propagate though the network. 1522 The split horizon rule states: 1523 Never advertise a route out of the interface through which it was learned. 1525 EIGRP implements this to mean if you have a Successor route to a destination, 1526 never advertise the route out the interface on which it was learned. 1528 Savage, et al. Expires August 16, 2015 [29] 1529 The poison reverse rule states: 1530 A route learned through an interface will be advertised as unreachable 1531 through that same interface. 1533 Again, as with the case of Split Horizon, EIGRP implements rule as it applies to 1534 the interface for which the Successor route was learned. 1536 In EIGRP, split horizon suppresses a QUERY, where as Reverse Poison advertises a 1537 destination as unreachable. This can occur for a destination under any of the 1538 following conditions: 1539 o two routers are in startup or restart mode 1540 o advertising a topology table change 1541 o sending a query 1543 5.4.7.3.1 Startup Mode 1544 When two routers first become neighbors, they exchange topology tables during 1545 startup mode. For each destination a router receives during startup mode, it 1546 advertises the same destination back to its new neighbor with a maximum metric 1547 (Poison Route). 1549 5.4.7.3.2 Advertising Topology Table Change 1550 If a router uses a neighbor as the Successor for a given destination, it will 1551 send an UPDATE for the destination with a metric of infinity. 1553 5.4.7.3.3 Sending a QUERY/UPDATE 1554 In most cases EIGRP follows normal split-horizon rules. When a metric change is 1555 received from the Successor via QUERY or UPDATE that causes the route to go 1556 ACTIVE, the router will send a QUERY to neighbors on all interfaces except the 1557 interface toward the Successor. 1559 In other words, the router does not send the QUERY out of the inbound interface 1560 through which the information causing the route to go ACTIVE was received. 1562 An exception to this can occur if a router receives a QUERY from its successor 1563 while already reacting to an event that did not cause it to go ACTIVE. For 1564 example, a metric change from the Successor that did not cause an ACTIVE 1565 transition, but was followed by the UPDATE/QUERY that does result the router to 1566 transition to ACTIVE. 1568 5.5 EIGRP Metric Coefficients 1569 EIGRP allows for modification of the default composite metric calculation 1570 through the use of coefficients (K-values). This adjustment allows for per- 1571 deployment tuning of network behavior. Setting K-values up to 254 scales the 1572 impact of the scalar metric on the final composite metric. 1574 EIGRP default coefficients have been carefully selected to provide optimal 1575 performance in most networks. The default K-values are 1577 K1 == K3 == 1 1578 K2 == K4 == K5 == 0 1579 K6 == 0 1581 If K5 is equal to 0 then reliability quotient is defined to be 1. 1583 Savage, et al. Expires August 16, 2015 [30] 1584 5.5.1 Coefficients K1 and K2 1585 K1 is used to allow path selection to be based on the bandwidth available along 1586 the path. EIGRP can use one of two variations of Throughput based path 1587 selection. 1588 o Maximum Theoretical Bandwidth; paths chosen based on the highest reported 1589 bandwidth 1590 o Network Throughput: paths chosen based on the highest available bandwidth 1591 adjusted by congestion-based effects (interface reported load) 1593 By default EIGRP computes the Throughput using the maximum theoretical 1594 throughput expressed in picoseconds per kilobyte of data sent. This inversion 1595 results in a larger number (more time) ultimately generating a worse metric. 1597 If K2 is used, the effect of congestion as a measure of load reported by the 1598 interface will be used to simulate the available throughput by adjusting the 1599 maximum throughput. 1601 5.5.2 Coefficient K3 1602 K3 is used to allow delay or latency-based path selection. Latency and Delay 1603 are similar terms that refer to the amount of time it takes a bit to be 1604 transmitted to an adjacent neighbor. EIGRP uses one-way based values either 1605 provided by the interface, or computed as a factor of the links bandwidth. 1607 5.5.3 Coefficients K4 and K5 1608 K4 and K5 are used to allow for path selection based on link quality and packet 1609 loss. Packet loss caused by network problems result in highly noticeable 1610 performance issues or jitter with streaming technologies, voice over IP, online 1611 gaming and videoconferencing, and will affect all other network applications to 1612 one degree or another. 1614 Critical services should pass with less than 1% packet loss. Lower priority 1615 packet types might pass with less than 5% and then 10% for the lowest of 1616 priority of services. The final metric can be weighted based on the reported 1617 link quality. 1619 The handling of K5 is conditional. If K5 is equal to 0 then reliability 1620 quotient is defined to be 1. 1622 5.5.4 Coefficient K6 1623 K6 has been introduced with Wide Metric support and is used to allow for 1624 Extended Attributes, which can be used to reflect in a higher aggregate metric 1625 than those having lower energy usage. 1626 Currently there are two Extended Attributes, jitter and energy, defined in the 1627 scope of this document. 1629 5.5.4.1 Jitter 1630 Use of Jitter-based Path Selection results in a path calculation with the lowest 1631 reported jitter. Jitter is reported as the interval between the longest and 1632 shortest packet delivery and is expressed in microseconds. Higher values results 1633 in a higher aggregate metric when compared to those having lower jitter 1634 calculations. 1636 Jitter is measured in microseconds and is accumulated along the path, with each 1637 hop using an averaged 3-second period to smooth out the metric change rate. 1639 Presently, EIGRP does not currently have the ability to measure jitter, and as 1640 such the default value will be zero (0). Performance based solutions such as 1642 Savage, et al. Expires August 16, 2015 [31] 1643 PfR could be used to populate this field. 1645 5.5.4.2 Energy 1646 Use of Energy-based Path Selection results in paths with the lowest energy usage 1647 being selected in a loop free and deterministic manner. The amount of energy 1648 used is accumulative and has results in a higher aggregate metric than those 1649 having lower energy. 1651 Presently, EIGRP does not report energy usage, and as such the default value 1652 will be zero (0). 1654 5.6 EIGRP Metric Calculations 1656 5.6.1 Classic Metrics 1657 One of the original goals of EIGRP was to offer and enhance routing solutions 1658 for IGRP. To achieve this, EIGRP used the same composite metric as IGRP, with 1659 the terms multiplied by 256 to change the metric from 24 bits to 32 bits. 1661 The composite metric is based on bandwidth, delay, load, and reliability. MTU is 1662 not an attribute for calculating the composite metric. 1664 5.6.1.1 Classic Composite Formulation 1665 EIGRP calculates the composite metric with the following formula: 1667 metric = {K1*BW+[(K2*BW)/(256 load)]+(K3*delay)}*{K5/(REL+K4)} 1669 In this formula, Bandwidth (BW) is the lowest interface bandwidth along the 1670 path, and delay is the sum of all outbound interface delays along the path. The 1671 router dynamically measures reliability (REL) and load. It expresses 100 percent 1672 reliability as 255/255. It expresses load as a fraction of 255. An interface 1673 with no load is represented as 1/255. 1675 Bandwidth is the inverse minimum bandwidth (in kbps) of the path in bits per 1676 second scaled by a factor of 256 multiplied by 10^7. The formula for bandwidth 1677 is 1679 (256 x (10 ^ 7))/BWmin 1681 The delay is the sum of the outgoing interface delay (in microseconds) to the 1682 destination. A delay set to it maximum value (hexadecimal 0xFFFFFFFF) indicates 1683 that the network is unreachable. The formula for delay is 1685 [sum of delays] x 256 1687 Reliability is a value between 1 and 255. Cisco IOS routers display reliability 1688 as a fraction of 255. That is, 255/255 is 100 percent reliability or a perfectly 1689 stable link; a value of 229/255 represents a 90 percent reliable link. Load is 1690 a value between 1 and 255. A load of 255/255 indicates a completely saturated 1691 link. A load of 127/255 represents a 50 percent saturated link. 1693 The default composite metric, adjusted for scaling factors, for EIGRP is: 1695 metric = 256 x { [(10^7)/ BWmin] + [sum of delays]} 1697 Minimum Bandwidth (BWmin) is represented in kbps, and the sum of delays is 1698 represented in 10s of microseconds. The bandwidth and delay for an Ethernet 1699 interface are 10Mbps and 1ms, respectively. 1701 Savage, et al. Expires August 16, 2015 [32] 1702 The calculated EIGRP bandwidth (BW) metric is then: 1704 256 x (10^7)/BW = 256 x {(10^7)/10,000} 1705 = 256 x 10,000 1706 = 256,00 1708 And the calculated EIGRP delay metric is then: 1710 256 x sum of delay = 256 x 100 x 10 microseconds 1711 = 25,600 (in tens of microseconds) 1713 5.5.1.2 Cisco Interface Delay Compatibility 1714 For compatibility with Cisco products, the following table shows the times in 1715 picoseconds EIGRP uses for bandwidth and delay 1716 Bandwidth Classic Wide Metrics Interface 1717 (Kbps) Delay Delay Type 1718 --------------------------------------------------------- 1719 9 500000000 500000000 Tunnel 1720 56 20000000 20000000 56Kb/s 1721 64 20000000 20000000 DS0 1722 1544 20000000 20000000 T1 1723 2048 20000000 20000000 E1 1724 10000 1000000 1000000 Ethernet 1725 16000 630000 630000 TokRing16 1726 45045 20000000 20000000 HSSI 1727 100000 100000 100000 FDDI 1728 100000 100000 100000 FastEthernet 1729 155000 100000 100000 ATM 155Mb/s 1730 1000000 10000 10000 GigaEthernet 1731 2000000 10000 5000 2 Gig 1732 5000000 10000 2000 5 Gig 1733 10000000 10000 1000 10 Gig 1734 20000000 10000 500 20 Gig 1735 50000000 10000 200 50 Gig 1736 100000000 10000 100 100 Gig 1737 200000000 10000 50 200 Gig 1738 500000000 10000 20 500 Gig 1740 Savage, et al. Expires August 16, 2015 [33] 1741 5.6.2 Wide Metrics 1742 To accommodate interfaces with high bandwidths, and to allow EIGRP to perform 1743 the path selection; the EIGRP packet and composite metric formula has been 1744 modified to choose paths based on the computed time, measured in picoseconds, 1745 information takes to travel though the links. 1747 5.6.2.1 Wide Metric Vectors 1748 EIGRP uses five vector metrics: minimum throughput, latency, load, 1749 reliability, and maximum transmission unit (MTU). These values are calculated 1750 from destination to source as follows: 1751 o Throughput - Minimum value 1752 o Latency - accumulative 1753 o Load - maximum 1754 o Reliability - minimum 1755 o MTU - minimum 1756 o Hop count - accumulative 1758 To this there are two additional values: jitter and energy. These two values are 1759 accumulated from destination to source: 1760 o Jitter - accumulative 1761 o Energy - accumulative 1763 These Extended Attributes, as well as any future ones, will be controlled via 1764 K6. If K6 is non-zero, these will be additive to the path s composite metric. 1765 Higher jitter or energy usage will result in paths that are worse than those 1766 which either does not monitor these attributes, or which have lower values. 1768 EIGRP will not send these attributes if the router does not provide them. If 1769 the attributes are received, then EIGRP will use them in the metric calculation 1770 (based on K6) and will forward them with those routers values assumed to be 1771 zero and the accumulative values are forwarded unchanged. 1773 The use of the vector metrics allows EIGRP to compute paths based on any of four 1774 (bandwidth, delay, reliability, and load) path selection schemes. The schemes 1775 are distinguished based on the choice of the key measured network performance 1776 metric. 1778 Of these vector metric components, by default, only minimum throughput and 1779 latency are traditionally used to compute best path. Unlike most metrics, 1780 minimum throughput is set to the minimum value of the entire path, and it does 1781 not reflect how many hops or low throughput links are in the path, nor does it 1782 reflect the availability of parallel links. Latency is calculated based on one- 1783 way delays, and is a cumulative value, which increases with each segment in the 1784 path. 1786 Network Designers Note: when trying to manually influence EIGRP path selection 1787 though interface bandwidth/delay configuration, the modification of bandwidth is 1788 discouraged for following reasons: 1790 The change will only effect the path selection if the configured value is the 1791 lowest bandwidth over the entire path. 1792 Changing the bandwidth can have impact beyond affecting the EIGRP metrics. For 1793 example, Quality of Service (QoS) also looks at the bandwidth on an interface. 1795 EIGRP throttles its packet transmissions so it will only use 50 percent of the 1796 configured bandwidth. Lowering the bandwidth can cause EIGRP to starve an 1797 adjacency, causing slow or failed convergence and control plane operation. 1799 Savage, et al. Expires August 16, 2015 [34] 1800 Changing the delay does not impact other protocols nor does it cause EIGRP to 1801 throttle back; changing the delay configured on a link only impacts metric 1802 calculation. 1804 5.6.2.2 Wide Metric Conversion Constants 1805 EIGRP uses a number of defined constants for conversion and calculation of 1806 metric values. These numbers are provided here for reference 1808 EIGRP_BANDWIDTH 10,000,000 1809 EIGRP_DELAY_PICO 1,000,000 1810 EIGRP_INACCESSIBLE 0xFFFFFFFFFFFFFFFFLL 1811 EIGRP_MAX_HOPS 100 1812 EIGRP_CLASSIC_SCALE 256 1813 EIGRP_WIDE_SCALE 65536 1815 When computing the metric using the above units, all capacity information will 1816 be normalized to kilobytes and picoseconds before being used. For example, 1817 delay is expressed in microseconds per kilobyte, and would be converted to 1818 kilobytes per second; likewise energy would be expressed in power per kilobytes 1819 per second of usage. 1821 5.6.2.3 Throughput Calculation 1822 The formula for the conversion for Max-Throughput value directly from the 1823 interface without consideration of congestion-based effects is as follows: 1825 (EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE) 1826 Max-Throughput = K1 * ------------------------------------ 1827 Interface Bandwidth (kbps) 1829 If K2 is used, the effect of congestion as a measure of load reported by the 1830 interface will be used to simulate the available throughput by adjusting the 1831 maximum throughput according to the formula: 1833 K2 * Max-Throughput 1834 Net-Throughput = Max-Throughput + --------------------- 1835 256 Load 1836 K2 has the greatest effect on the metric occurs when the load increases beyond 1837 90%. 1839 5.6.2.4 Latency Calculation 1840 Transmission times derived from physical interfaces MUST be n units of 1841 picoseconds, or converted to picoseconds prior to being exchanged between 1842 neighbors, or used in the composite metric determination. 1844 This includes delay values present in configuration-based commands (i.e. 1845 interface delay, redistribute, default-metric, route-map, etc.) 1847 The delay value is then converted to a latency using the formula: 1849 Delay * EIGRP_WIDE_SCALE 1850 Latency = K3 * -------------------------- 1851 EIGRP_DELAY_PICO 1853 Savage, et al. Expires August 16, 2015 [35] 1854 5.6.2.5 Composite Calculation 1855 K5 1856 metric =[(K1*Net-Throughput) + Latency)+(K6*ExtAttr)] * ------ 1857 K4+Rel 1859 By default, the path selection scheme used by EIGRP is a combination of 1860 Throughput and Latency where the selection is a product of total latency and 1861 minimum throughput of all links along the path: 1863 metric = (K1 * min(Throughput)) + (K3 * sum(Latency)) } 1865 6 Security Considerations 1866 By the nature of being promiscuous, EIGRP will neighbor with any router that 1867 sends a valid HELLO packet. Due to security considerations, this completely 1868 open aspect requires policy capabilities to limit peering to valid routers. 1870 EIGRP does not rely on a PKI or a more heavy weight authentication system. These 1871 systems challenge the scalability of EIGRP, which was a primary design goal. 1873 Instead, Denial of Service (DoS) attack prevention will depend on 1874 implementations rate-limiting packets to the control plane as well as 1875 authentication of the neighbor though the use of MD5 or SHA2-256 1877 Savage, et al. Expires August 16, 2015 [36] 1878 7 IANA Considerations 1879 This draft references the two multicast addresses: 1881 224.0.0.10 IGRP Routers [multicast-addresses] 1882 FF02:0:0:0:0:0:0:A EIGRP Routers [ipv6-multicast-addresses] 1884 Please see 1885 http://www.iana.org/assignments/multicast-addresses 1886 http://www.iana.org/assignments/ipv6-multicast-addresses 1888 8 References 1890 8.1 Normative References 1891 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1892 Levels", BCP 14, [RFC2119], April 1997. 1894 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 1895 Specifications: ABNF", [RFC5234], Internet Mail Consortium and Demon Internet 1896 Ltd., November 1997. 1898 [3] A Unified Approach to Loop-Free Routing using Distance Vectors or 1899 Link States, J.J. Garcia-Luna-Aceves, 1989 ACM 089791-332-9/89/0009/0212, pages 1900 212-223. 1902 [4] Loop-Free Routing using Diffusing Computations, J.J. Garcia-Luna- 1903 Aceves, Network Information Systems Center, SRI International to appear in 1904 IEEE/ACM Transactions on Networking, Vol. 1, No. 1, 1993. 1906 [5] BGP Extended Communities Attribute [RFC4360] 1908 [6] Assigning Experimental and Testing Numbers Considered Useful 1909 [RFC3692] 1911 [7] HMAC-SHA256, SHA384, SHA512 in IPsec [RFC4868] 1913 8.2 Informative References 1914 [8] OSPF Version 2, Network Working Group [RFC2328], J. Moy, April 1998. 1916 [9] Guidelines for Considering New Performance Metric Development 1917 [RFC6390] 1919 [10] Address Family Numbers, http://www.iana.org/assignments/address- 1920 family-numbers/address-family-numbers.xhtml#address-family-numbers-2 1922 Savage, et al. Expires August 16, 2015 [37] 1923 9 Acknowledgments 1924 This document was prepared using 2-Word-v2.0.template.dot. 1926 An initial thank you goes to Dino Farinacci, Bob Albrightson, and Dave Katz. 1927 Their significant accomplishments towards the design and development of the 1928 EIGRP protocol provided the bases for this document. 1930 A special and appreciative thank you goes to the core group of Cisco engineers 1931 whose dedication, long hours, and hard work lead the evolution of EIGRP over the 1932 following decade. They are Donnie Savage, Mickel Ravizza, Heidi Ou, Dawn Li, 1933 Thuan Tran, Catherine Tran, Don Slice, Claude Cartee, Donald Sharp, Steven 1934 Moore, Richard Wellum, Ray Romney, Jim Mollmann, Dennis Wind, Chris Van Heuveln, 1935 Gerald Redwine, Glen Matthews, Michael Wiebe, and others. 1937 The authors would like to gratefully acknowledge many people who have 1938 contributed to the discussions that lead to the making of this proposal. They 1939 include Chris Le, Saul Adler, Scott Van de Houten, Lalit Kumar, Yi Yang, Kumar 1940 Reddy, David Lapier, Scott Kirby, David Prall, Jason Frazier, Eric Voit, Dana 1941 Blair, Jim Guichard, and Alvaro Retana. 1943 In addition to the tireless work provided by the Cisco engineers over the years, 1944 I would like to personally call out the team what crated the first Open Source 1945 verison of EIGRP. This team comprises of: Jan Janovic, Matej Perina, Peter 1946 Orsag, and Peter Paluch who made it all possible. 1948 Savage, et al. Expires August 16, 2015 [38] 1949 10 EIGRP Packet Formats 1951 10.1 Protocol Number 1952 The IPv6 and IPv4 protocol identifier number spaces are common and will both use 1953 protocol identifier 88. 1955 EIGRP IPv6 will transmit HELLO packets with a source address being the link- 1956 local address of the transmitting interface. Multicast HELLO packets will have a 1957 destination address of FF02::A (the EIGRP IPv6 multicast address). Unicast 1958 packets directed to a specific neighbor will contain the destination link-local 1959 address of the neighbor. 1961 There is no requirement that two EIGRP IPv6 neighbors share a common prefix on 1962 their connecting interface. EIGRP IPv6 will check that a received HELLO contains 1963 a valid IPv6 link-local source address. Other HELLO processing will follow 1964 common EIGRP checks, including matching Autonomous system number and matching K- 1965 values. 1967 10.2 Protocol Assignment Encoding 1968 External Protocol Field is an informational assignment to identify the 1969 originating routing protocol that this route was learned by. The following 1970 values are assigned: 1972 Protocols Value 1973 IGRP 1 1974 EIGRP 2 1975 Static 3 1976 RIP 4 1977 HELLO 5 1978 OSPF 6 1979 ISIS 7 1980 EGP 8 1981 BGP 9 1982 IDRP 10 1983 Connected 11 1985 10.3 Destination Assignment Encoding 1986 Destinations types are encoded according to the IANA address family number 1987 assignments. Currently on the following types are used: 1989 AFI Designation AFI Value 1990 -------------------------------------- 1991 IPv4 Address 1 1992 IPv6 Address 2 1993 Service Family Common 16384 1994 Service Family IPv4 16385 1995 Service Family IPv6 16386 1997 Savage, et al. Expires August 16, 2015 [39] 1998 10.4 EIGRP Communities Attribute 1999 EIGRP supports communities similar to the BGP Extended Communities [5] extended 2000 type with Type Field composed of 2 octets and Value Field composed of 6 octets. 2001 Each Community is encoded as an 8-octet quantity, as follows: 2002 - Type Field: 2 octets 2003 - Value Field: Remaining octets 2005 0 1 2 3 2006 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 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 | Type high | Type low | | 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | 2010 | | 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 In addition to well-known communities supported by BGP (such as Site of Origin), 2014 EIGRP defines a number of additional Community values in the Experimental Use 2015 [6] range as follows: 2017 Type high: 0x88 2018 Type low: 2020 Value Name Description 2021 --------------------------------------------------------------- 2022 00 EXTCOMM_EIGRP EIGRP route information appended 2023 01 EXTCOMM_DAD Data: AS + Delay 2024 02 EXTCOMM_VRHB Vector: Reliability + Hop + BW 2025 03 EXTCOMM_SRLM System: Reserve +Load + MTU 2026 04 EXTCOMM_SAR System: Remote AS + Remote ID 2027 05 EXTCOMM_RPM Remote: Protocol + Metric 2028 06 EXTCOMM_VRR Vecmet: Rsvd + RouterID 2030 10.5 EIGRP Packet Header 2031 The basic EIGRP packet payload format is identical for all three protocols, 2032 although there are some protocol-specific variations. Packets consist of a 2033 header, followed by a set of variable-length fields consisting of 2034 Type/Length/Value (TLV) triplets. 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 |Header Version | Opcode | Checksum | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 | Flags | 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 | Sequence Number | 2044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2045 | Acknowledgement number | 2046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2047 | Virtual Router ID | Autonomous system number | 2048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2050 Header Version - EIGRP Packet Header Format version. Current Version is 2. 2051 This field is not the same as the TLV Version field. 2053 Savage, et al. Expires August 16, 2015 [40] 2054 Opcode - EIGRP opcode indicating function packet serves. It will be one of the 2055 following values: 2057 EIGRP_OPC_UPDATE 1 2058 EIGRP_OPC_REQUEST 2 2059 EIGRP_OPC_QUERY 4 2060 EIGRP_OPC_REPLY 4 2061 EIGRP_OPC_HELLO 5 2062 Reserved 6 2063 Reserved 7 2064 Reserved 8 2065 Reserved 9 2066 EIGRP_OPC_SIAQUERY 10 2067 EIGRP_OPC_SIAREPLY 11 2069 Checksum - Each packet will include a checksum for the entire contents of the 2070 packet. The check-sum will be the standard ones complement of the ones 2071 complement sum. The packet is discarded if the packet checksum fails. 2073 Flags - Defines special handling of the packet. There are currently two defined 2074 flag bits. 2076 Init Flag (0x01) - This bit is set in the initial UPDATE sent to a newly 2077 discovered neighbor. It requests the neighbor to download a full set of routes. 2079 CR Flag (0x02) - This bit indicates that receivers should only accept the packet 2080 if they are in Conditionally Received mode. A router enters conditionally 2081 received mode when it receives and processes a HELLO packet with a Sequence TLV 2082 present. 2084 RS (0x04) - The Restart flag is set in the HELLO and the UPDATE packets during 2085 the restart period. The router looks at the RS flag to detect if a neighbor is 2086 restarting, From the restarting routers perspective, if a neighboring router 2087 detects the RS flag set, it will maintains the adjacency, and will set the RS 2088 flag in its UPDATE packet to indicated it is doing a soft restart. 2090 EOT (0x08) - The End-of-Table flag marks the end of the startup process with a 2091 neighbor. If the flag is set, it indicates the neighbor has completed sending 2092 all UPDATEs. At this point the router will remove any stale routes learned from 2093 the neighbor prior to the restart event. A state route is any route, which 2094 existed before the restart, and was not refreshed by the neighbor via and 2095 UPDATE. 2097 Sequence - Each packet that is transmitted will have a 32-bit sequence number 2098 that is unique respect to a sending router. A value of 0 means that an 2099 acknowledgment is not required. 2101 ACK The 32-bit sequence number that is being acknowledged with respect to 2102 receiver of the packet. If the value is 0, there is no acknowledgment present. A 2103 non-zero value can only be present in unicast-addressed packets. A HELLO packet 2104 with a nonzero ACK field should be decoded as an ACK packet rather than a HELLO 2105 packet. 2107 Savage, et al. Expires August 16, 2015 [41] 2108 Virtual Router ID (VRID) A 16-bit number, which identifies the virtual router, 2109 this packet is associated. Packets received with an unknown, or unsupported VRID 2110 will be discarded. 2112 Value Range Usage 2113 0000 Unicast Address Family 2114 0001 Multicast Address Family 2115 0002-7FFFF Reserved 2116 8000 Unicast Service Family 2117 8001-FFFF Reserved 2119 Autonomous System (AS) 16 bit unsigned number of the sending system. This 2120 field is indirectly used as an authentication value. That is, a router that 2121 receives and accepts a packet from a neighbor must have the same AS number or 2122 the packet is ignored. 2124 10.6 EIGRP TLV Encoding Format 2125 The contents of each packet can contain a variable number of fields. Each field 2126 will be tagged and include a length field. This allows for newer versions of 2127 software to add capabilities and coexist with old versions of software in the 2128 same configuration. Fields that are tagged and not recognized can be skipped 2129 over. Another advantage of this encoding scheme allows multiple network layer 2130 protocols to carry independent information. Therefore, later if it is decided to 2131 implement a single integrated protocol this can be done. 2133 The format of a {type, length, value} (TLV) is encoded as follows: 2135 0 1 2 3 2136 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 2137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2138 | Type high | Type low | Length | 2139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2140 | Value (variable length) | 2141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 The type values are the ones defined below. The length value specifies the 2144 length in octets of the type, length and value fields. TLVs can appear in a 2145 packet in any order and there are no inter-dependencies among them. 2147 10.6.1 Type Field Encoding 2148 The type field is structured as follows: 2149 Type High: 1 octet that defines the protocol classification: 2150 Protocol ID VERSION 2151 General 0x00 1.2 2152 IPv4 0x01 1.2 2153 IPv6 0x04 1.2 2154 SAF 0x05 3.0 2155 Multi-Protocol 0x06 2.0 2157 Type Low: 1 octet that defines the TLV Opcode 2158 See TLV Definitions in Section 3 2160 10.6.2 Length Field Encoding 2161 The Length field is a 2 octet unsigned number, which indicates the length of the 2162 TLV. The value does includes the Type and Length fields 2164 Savage, et al. Expires August 16, 2015 [42] 2165 10.6.3 Value Field Encoding 2166 The Value field is a multi-octet field containing the payload for the TLV. 2168 10.7 EIGRP Generic TLV Definitions 2169 Ver 1.2 Ver 2.0 2170 PARAMETER_TYPE 0x0001 0x0001 2171 AUTHENTICATION_TYPE 0x0002 0x0002 2172 SEQUENCE_TYPE 0x0003 0x0003 2173 SOFTWARE_VERSION_TYPE 0x0004 0x0004 2174 MULTICAST_SEQUENCE _TYPE 0x0005 0x0005 2175 PEER_INFORMATION _TYPE 0x0006 0x0006 2176 PEER_TERMINATION_TYPE 0x0007 0x0007 2177 PEER_TID_LIST_TYPE --- 0x0008 2179 10.7.1 0x0001 - PARAMETER_TYPE 2180 This TLV is used in HELLO packets to convey the EIGRP metric coefficient values 2181 noted as K-values as well as the Hold Time values. This TLV is also used in 2182 an initial UPDATE packet when a neighbor is discovered. 2184 0 1 2 3 2185 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 2186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 | 0x0001 | 0x000C | 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 | K1 | K2 | K3 | K4 | 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 | K5 | K6 | Hold Time | 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 K-values - The K-values associated with the EIGRP composite metric equation. 2195 The default values for weights are: 2196 K1 - 1 2197 K2 - 0 2198 K3 - 1 2199 K4 - 0 2200 K5 - 0 2201 K6 0 2203 Hold Time - The amount of time in seconds that a receiving router should 2204 consider the sending neighbor valid. A valid neighbor is one that is able to 2205 forward packets and participates in EIGRP. A router that considers a neighbor 2206 valid will store all routing information advertised by the neighbor. 2208 10.7.2 0x0002 - AUTHENTICATION_TYPE 2209 This TLV may be used in any EIGRP packet and conveys the authentication type and 2210 data used. Routers receiving a mismatch in authentication shall discard the 2211 packet. 2213 0 1 2 3 2214 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 2215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2216 | 0x0002 | Length | 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 | Auth Type | Auth Length | Auth Data (Variable) | 2219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 Authentication Type - The type of authentication used. 2223 Savage, et al. Expires August 16, 2015 [43] 2224 Authentication Length - The length, measured in octets, of the individual 2225 authentication. 2227 Authentication Data - Variable length field reflected by Auth Length which is 2228 dependent on the type of authentication used. Multiple authentication types can 2229 be present in a single AUTHENTICATION_TYPE TLV. 2231 10.7.2.1 0x02 - MD5 Authentication Type 2232 MD5 Authentication will use Auth Type code 0x02, and the Auth Data will be the 2233 MD5 Hash value. 2235 10.7.2.2 0x03 - SHA2 Authentication Type 2236 SHA2-256 Authentication will use Type code 0x03, and the Auth Data will be the 2237 256 bit SHA2 [6] Hash value 2239 10.7.3 0x0003 - SEQUENCE_TYPE 2240 This TLV is used for a sender to tell receivers to not accept packets with the 2241 CR-flag set. This is used to order multicast and unicast addressed packets. 2243 0 1 2 3 2244 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 2245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 | 0x0003 | Length | 2247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2248 |Address Length | Protocol Address | 2249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 The Address Length and Protocol Address will be repeated one or more times based 2252 on the Length Field. 2254 Address Length - Number of octets for the address that follows. For IPv4, the 2255 value is 4. For AppleTalk, the value is 4. For Novell IPX, the value is 10, for 2256 IPv6 it is 16 2258 Protocol Address - Neighbor address on interface in which the HELLO with 2259 SEQUENCE TLV is sent. Each address listed in the HELLO packet is a neighbor that 2260 should not enter Conditionally Received mode. 2262 10.7.4 0x0004 - SOFTWARE_VERSION_TYPE 2263 Field Length 2264 Vender OS major version 1 2265 Vender OS minor version 1 2266 EIGRP major revision 1 2267 EIGRP minor revision 1 2269 The EIGRP TLV Version fields are used to determine TLV format versions. Routers 2270 using Version 1.2 TLVs do not understand version 2.0 TLVs, therefore Version 2.0 2271 routers must send the packet with both TLV formats in a mixed network. 2273 10.7.5 0x0005 - MULTICAST_SEQUENCE_TYPE 2274 The next multicast sequence TLV 2276 10.7.6 0x0006 - PEER_INFORMATION_TYPE 2277 This TLV is reserved, and not part of this IETF draft. 2279 Savage, et al. Expires August 16, 2015 [44] 2280 10.7.7 0x0007 - PEER_TERMAINATION_TYPE 2281 This TLV is used in HELLO Packets to specify a given neighbor has been reset. 2283 0 1 2 3 2284 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 2285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2286 | 0x0007 | Length | 2287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2288 | Address List (variable) | 2289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2291 10.7.8 0x0008 - TID_LIST_TYPE 2292 List of sub-topology identifiers, including the base topology, supported but the 2293 router. 2295 0 1 2 3 2296 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 2297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2298 | 0x0008 | Length | 2299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2300 | Topology Identification List (variable) | 2301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2303 If this information changes from the last state, it means either a new topology 2304 was added, or an existing topology was removed. This TLV is ignored until 2305 three-way handshake has finished 2307 When the TID list received, it compares the list to the previous list sent. If 2308 a TID is found which does not previously exist, the TID is added to the 2309 neighbor s topology list, and the existing sub-topology is sent to the peer. 2311 If a TID, which was in a previous list, is not found, the TID is removed from 2312 the neighbor s topology list and all routes learned though that neighbor for 2313 that sub-topology is removed from the topology table. 2315 10.8 Classic Route Information TLV Types 2317 10.8.1 Classic Flag Field Encoding 2318 EIGRP transports a number of flags with in the TLVs to indicate addition route 2319 state information. These bits are defined as follows: 2321 Flags Field 2322 ----------- 2323 Source Withdraw (Bit 0) - Indicates if the router which is the original source 2324 of the destination is withdrawing the route from the network, or if the 2325 destination is lost due as a result of a network failure. 2327 Candidate Default (CD) (Bit 1) Set to indicate the destination should be 2328 regarded as a candidate for the default route. An EIGRP default route is 2329 selected from all the advertised candidate default routes with the smallest 2330 metric. 2332 ACTIVE (Bit 2) - Indicates if the route is in the ACTIVE State. 2334 Savage, et al. Expires August 16, 2015 [45] 2335 10.8.2 Classic Metric Encoding 2336 The handling of bandwidth and delay for Classic TLVs are encoded in the packet 2337 scaled form relative to how they are represented on the physical link. 2339 0 1 2 3 2340 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 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 | Scaled Delay | 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2344 | Scaled Bandwidth | 2345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2346 | MTU | Hop-Count | 2347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2348 | Reliability | Load | Internal Tag | Flags Field | 2349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 Scaled Delay - An administrative parameter assigned statically on a per 2352 interface type basis to represent the time it takes a along an unloaded path. 2353 This is expressed in units of 10s of microseconds divvied by 256. A delay of 2354 0xFFFFFFFF indicates an unreachable route. 2356 Scaled Bandwidth - The path bandwidth measured in bits per second. In units of 2357 2,560,000,000/kbps 2358 MTU - The minimum maximum transmission unit size for the path to the 2359 destination. 2361 Hop Count - The number of router traversals to the destination. 2363 Reliability - The current error rate for the path. Measured as an error 2364 percentage. A value of 255 indicates 100% reliability 2366 Load - The load utilization of the path to the destination, measured as a 2367 percentage. A value of 255 indicates 100% load. 2369 Internal-Tag - A tag assigned by the network administrator that is untouched by 2370 EIGRP. This allows a network administrator to filter routes in other EIGRP 2371 border routers based on this value. 2373 Flag Field - See Section 10.8.1 2375 10.8.3 Classic Exterior Encoding 2376 Additional routing information so provided for destinations outside of the EIGRP 2377 autonomous system as follows: 2379 0 1 2 3 2380 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 2381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2382 | Router Identification (RID) | 2383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2384 | Autonomous System Number (AS) | 2385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2386 | External Protocol Metric | 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 | Reserved |Extern Protocol| Flags Field | 2389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2391 Router Identifier (RID) A 32bit number provided by the router sourcing the 2392 information to uniquely identify it as the source. 2394 Savage, et al. Expires August 16, 2015 [46] 2395 Autonomous System (AS) 32-bit number indicating the external autonomous system 2396 the sending router is a member of. If the source protocol is EIGRP, this field 2397 will be the [VRID|AS] pair. 2399 External Protocol Metric 32bit value of the composite metric that resides in 2400 the routing table as learned by the foreign protocol. If the External Protocol 2401 is IGRP or another EIGRP routing process, the value can optionally be the 2402 composite metric or 0, and the metric information is stored in the metric 2403 section. 2405 External Protocol - Defines the external protocol that this route was learned. 2406 See Section 10.2 2408 Flag Field - See Section 10.8.1 2410 10.8.4 Classic Destination Encoding 2411 EIGRP carries destination in a compressed form, where the number of bits 2412 significant in the variable length address field are indicated in a counter 2414 0 1 2 3 2415 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 2416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2417 | Subnet Mask | Destination Address (variable length | 2418 | Bit Count | ((Bit Count - 1) / 8) + 1 | 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2421 Subnet Mask Bit Count 8-bit value used to indicate the number of bits in the 2422 subnet mask. A value of 0 indicates the default network and no address is 2423 present. 2425 Destination Address A variable length field used o carry the destination 2426 address. The length is determined by the number of consecutive bits in the 2427 destination address, rounded up to the nearest octet boundary, determines the 2428 length of the address. 2430 Savage, et al. Expires August 16, 2015 [47] 2431 10.8.5 IPv4 Specific TLVs 2432 INTERNAL_TYPE 0x0102 2433 EXTERNAL_TYPE 0x0103 2434 COMMUNITY_TYPE 0x0104 2436 10.8.5.1 IPv4 INTERNAL_TYPE 2437 This TLV conveys IPv4 destination and associated metric information for IPv4 2438 networks. Routes advertised in this TLV are network interfaces that EIGRP is 2439 configured on as well as networks that are learned via other routers running 2440 EIGRP. 2442 0 1 2 3 2443 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 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 | 0x01 | 0x02 | Length | 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | Next Hop Forwarding Address | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2449 | Vector Metric Section (See Section 10.8.2) | 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2451 | Destination Section | 2452 | IPv4 Address (variable length) | 2453 | (See Section 10.8.4) | 2454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 Next Hop Forwarding Address - IPv4 address is represented by 4 8-bit values 2457 (total 4 octets). If the value is zero (0), the IPv6 address from the received 2458 IPv4 header is used as the next-hop for the route. Otherwise, the specified IPv4 2459 address will be used. 2461 Metric Section vector metrics for destinations contained in this TLV. See 2462 description of metric encoding in section 10.8.2 2464 Destination Section - The network/subnet/host destination address being 2465 requested. See description of destination in section10.8.4 2467 10.8.5.2 IPv4 EXTERNAL_TYPE 2468 This TLV conveys IPv4 destination and metric information for routes learned by 2469 other routing protocols that EIGRP injects into the AS. Available with this 2470 information is the identity of the routing protocol that created the route, the 2471 external metric, the AS number, an indicator if it should be marked as part of 2472 the EIGRP AS, and a network administrator tag used for route filtering at EIGRP 2473 AS boundaries. 2475 0 1 2 3 2476 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 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2478 | 0x01 | 0x03 | Length | 2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 | Next Hop Forwarding Address | 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2482 | Exterior Section (See Section10.8.3) | 2483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2484 | Vector Metric Section (See Section 10.8.2) | 2485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2486 | Destination Section | 2487 | IPv4 Address (variable length) | 2488 | (See Section 10.8.4) | 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2491 Savage, et al. Expires August 16, 2015 [48] 2492 Next Hop Forwarding Address - IPv4 address is represented by 4 8-bit values 2493 (total 4 octets). If the value is zero (0), the IPv6 address from the received 2494 IPv4 header is used as the next-hop for the route. Otherwise, the specified IPv4 2495 address will be used 2497 Exterior Section Additional routing information provide for a destination 2498 outside of the autonomous system and that has been redistributed into the EIGRP. 2499 See Section 10.8.3 2501 Metric Section vector metrics for destinations contained in this TLV. See 2502 description of metric encoding in section 10.8.2 2504 Destination Section - The network/subnet/host destination address being 2505 requested. See description of destination in Section 10.8.4 2507 10.8.5.3 IPv4 COMMUNITY_TYPE 2508 This TLV is used to provide community tags for specific IPv4 destinations. 2510 0 1 2 3 2511 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 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2513 | 0x01 | 0x04 | Length | 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2515 | IPv4 Destination | 2516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2517 | Reserved | Community Length | 2518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2519 | Community List | 2520 | (variable length) | 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2523 Destination - The IPv4 address the community information should be stored with. 2525 Community Length - 2 octet unsigned number that indicates the length of the 2526 Community List. The length does not includes the IPv4 Address, reserved, or 2527 Length fields 2529 Community List One or more 8 octet EIGRP community as defined in section 10.4 2531 Savage, et al. Expires August 16, 2015 [49] 2532 10.8.6 IPv6 Specific TLVs 2533 REQUEST_TYPE 0x0401 2534 INTERNAL_TYPE 0x0402 2535 EXTERNAL_TYPE 0x0403 2537 10.8.6.1 IPv6 INTERNAL_TYPE 2538 This TLV conveys IPv6 destination and associated metric information for IPv6 2539 networks. Routes advertised in this TLV are network interfaces that EIGRP is 2540 configured on as well as networks that are learned via other routers running 2541 EIGRP. 2543 0 1 2 3 2544 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 2545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2546 | 0x04 | 0x02 | Length | 2547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2548 | Next Hop Forwarding Address | 2549 | (16 octets) | 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 | Vector Metric Section (See Section 10.8.2) | 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2553 | Destination Section | 2554 | IPv4 Address (variable length) | 2555 | (See Section 10.8.4) | 2556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 Next Hop Forwarding Address - IPv6 address is represented by 8 groups of 16-bit 2559 values (total 16 octets). If the value is zero (0), the IPv6 address from the 2560 received IPv6 header is used as the next-hop for the route. 2562 Metric Section vector metrics for destinations contained in this TLV. See 2563 description of metric encoding in section 10.8.2 2565 Destination Section - The network/subnet/host destination address being 2566 requested. See description of destination in section 10.8.4 2568 10.8.6.2 IPv6 EXTERNAL_TYPE 2569 This TLV conveys IPv6 destination and metric information for routes learned by 2570 other routing protocols that EIGRP injects into the. Available with this 2571 information is the identity of the routing protocol that created the route, the 2572 external metric, the AS number, an indicator if it should be marked as part of 2573 the EIGRP AS, and a network administrator tag used for route filtering at EIGRP 2574 AS boundaries. 2576 0 1 2 3 2577 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 2578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2579 | 0x04 | 0x03 | Length | 2580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2581 | Next Hop Forwarding Address | 2582 | (16 octets) | 2583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 | Exterior Section (See Section 10.8.3) | 2585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2586 | Vector Metric Section (See Section 10.8.2) | 2587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 2588 | Destination Section | 2589 | IPv4 Address (variable length) | 2590 | (See Section 10.8.4) | 2591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2593 Savage, et al. Expires August 16, 2015 [50] 2594 Next Hop Forwarding Address - IPv6 address is represented by 8 groups of 16-bit 2595 values (total 16 octets). If the value is zero (0), the IPv6 address from the 2596 received IPv6 header is used as the next-hop for the route. Otherwise, the 2597 specified IPv6 address will be used. 2599 Exterior Section Additional routing information provide for a destination 2600 outside of the autonomous system and that has been redistributed into the EIGRP. 2601 See Section 10.8.3 2603 Metric Section vector metrics for destinations contained in this TLV. See 2604 description of metric encoding in section 10.8.2 2606 Destination Section - The network/subnet/host destination address being 2607 requested. See description of destination in section 10.8.4 2609 10.8.6.3 IPv6 COMMUNITY_TYPE 2610 This TLV is used to provide community tags for specific IPv4 destinations. 2612 0 1 2 3 2613 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 2614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2615 | 0x01 | 0x04 | Length | 2616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2617 | Destination | 2618 | (16 octets) | 2619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2620 | Reserved | Community Length | 2621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2622 | Community List | 2623 | (variable length) | 2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2626 Destination - The IPv6 address the community information should be stored with. 2628 Community Length - 2 octet unsigned number that indicates the length of the 2629 Community List. The length does not includes the IPv4 Address, Reserved or 2630 Length fields 2632 Community List One or more 8 octet EIGRP community as defined in section 10.4 2634 Savage, et al. Expires August 16, 2015 [51] 2635 10.9 Multi-Protocol Route Information TLV Types 2636 This TLV conveys topology and associated metric information 2638 0 1 2 3 2639 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 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 |Header Version | Opcode | Checksum | 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 | Flags | 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2645 | Sequence Number | 2646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2647 | Acknowledgement number | 2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2649 | Virtual Router ID | Autonomous system number | 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2651 | TLV Header Encoding | 2652 | (See Section 10.9.1) | 2653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2654 | Wide Metric Encoding | 2655 | (See Section 10.9.2) | 2656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2657 | Destination Descriptor | 2658 | (variable length) | 2659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2661 10.9.1 TLV Header Encoding 2662 There has been a long-standing requirement for EIGRP to support routing 2663 technologies such as multi-topologies and provide the ability to carry 2664 destination information independent of the transport. To accomplish this, a 2665 Vector has been extended to have a new Header Extension Header section. This 2666 is a variable length field and, at a minimum, will support the following fields: 2668 0 1 2 3 2669 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 2670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2671 | Type high | Type low | Length | 2672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2673 | AFI | TID | 2674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2675 | Router Identifier (RID) | 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2677 | Value (variable length) | 2678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2680 The available fields are: 2681 TYPE - Topology TLVs have the following TYPE codes: 2683 Type High: 0x06 2684 Type Low: 2685 REQUEST_TYPE 0x01 2686 INTERNAL_TYPE 0x02 2687 EXTERNAL_TYPE 0x03 2689 Router Identifier (RID) A 32bit number provided by the router sourcing the 2690 information to uniquely identify it as the source. 2692 Savage, et al. Expires August 16, 2015 [52] 2693 10.9.2 Wide Metric Encoding 2694 Multi-Protocol TLV s will provide an extendable section of metric information, 2695 which is not used for the primary routing compilation. Additional per path 2696 information is included to enable per-path cost calculations in the future. Use 2697 of the per-path costing along with the VID/TID will prove a complete solution 2698 for multidimensional routing. 2700 0 1 2 3 2701 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 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 | Offset | Priority | Reliability | Load | 2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2705 | MTU | Hop-Count | 2706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2707 | Delay | 2708 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 | | | 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2711 | Bandwidth | 2712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2713 | Reserved | Opaque Flags | 2714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 | Extended Attributes | 2716 | (variable length) | 2717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2719 The fields are: 2720 Offset Number of 16bit words in the Extended Attribute section, used to 2721 determine the start of the destination information. If no Extended Attributes 2722 are attached, offset will be zero. 2724 Priority - Priority of the prefix when processing route. In an AS using priority 2725 values, a destination with a higher priority receives preferential treatment and 2726 is serviced before a destination with a lower priority. A priority of zero 2727 indicates no priority is set. 2729 Reliability - The current error rate for the path. Measured as an error 2730 percentage. A value of 255 indicates 100% reliability 2732 Load - The load utilization of the path to the destination, measured as a 2733 percentage. A value of 255 indicates 100% load. 2735 MTU - The minimum maximum transmission unit size for the path to the 2736 destination. Not used in metric calculation, but available to underlying 2737 protocols 2739 Hop Count - The number of router traversals to the destination. 2741 Delay The one-way latency along an unloaded path to the destination expressed 2742 in units of picoseconds per kilobit. This number is not scaled, a value of 2743 0xFFFFFFFFFFFF indicates an unreachable route. 2745 Bandwidth - The path bandwidth measured in kilobit per second as presented by 2746 the interface. This number is not scaled, as is the case with scaled 2747 bandwidth . A bandwidth of 0xFFFFFFFFFFFF indicates an unreachable route. 2749 Reserved Transmitted as 0x0000 2751 Opaque Flags 16 bit protocol specific flags. 2753 Savage, et al. Expires August 16, 2015 [53] 2754 Extended Attributes (Optional) When present, defines extendable per 2755 destination attributes. This field is not normally transmitted. 2757 10.9.3 Extended Metrics 2758 Extended metrics allows for extensibility of the vector metrics in a manor 2759 similar to RFC-6390 [9]. Each Extended metric shall consist of a standard Type- 2760 Length header followed by application-specific information. Extended metrics 2761 values not understood must be treated as opaque and passed along with the 2762 associated route. 2764 The general formats for the Extended Metric fields are: 2765 0 1 2 3 2766 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 2767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2768 | Opcode | Offset | Data | 2769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2771 Opcode Indicates the type of Extended Metric 2773 Offset Number of 16bit words in the sub-field. Offset does not include the 2774 length of the opcode or offset fields) 2776 Data Zero or more octets of data as defined by Opcode 2778 10.9.3.1 0x00 NoOp 2779 This is used to pad the attribute section to ensure 32-bit alignment of the 2780 metric encoding section. 2782 0 1 2 3 2783 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 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 | 0x00 | 0x00 | 2786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2788 The fields are: 2789 Opcode Transmitted as zero (0) 2791 Offset Transmitted as zero (0) indicating no data is present 2793 Data No data is present with this attribute. 2795 10.9.3.2 0x01 Scaled Metric 2796 If a route is received from a back-rev neighbor, and the route is selected as 2797 the best path, the scaled metric received in the older UPDATE, may be attached 2798 to the packet. If received, the value is for informational purposes, and is not 2799 affected by K6 2801 0 1 2 3 2802 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 2803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2804 | 0x01 | 0x04 | Reserved | 2805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2806 | Scaled Bandwidth | 2807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2808 | Scaled Delay | 2809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2811 Savage, et al. Expires August 16, 2015 [54] 2812 Reserved Transmitted as 0x0000 2814 Scaled Delay - An administrative parameter assigned statically on a per 2815 interface type basis to represent the time it takes a along an unloaded path. 2816 This is expressed in units of 10s of microseconds divvied by 256. A delay of 2817 0xFFFFFFFF indicates an unreachable route. 2819 Scaled Bandwidth - The minimum bandwidth along a path expressed in units of 2820 2,560,000,000/kbps. A bandwidth of 0xFFFFFFFF indicates an unreachable route. 2822 10.9.3.3 0x02 Administrator Tag 2823 This is used to provide and administrative tags for specific topology entries. 2824 It is not affected by K6 2826 0 1 2 3 2827 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 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 | 0x02 | 0x02 | Administrator Tag | 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2831 | Administrator Tag (cont) | 2832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2834 Administrator Tag - A tag assigned by the network administrator that is 2835 untouched by EIGRP. This allows a network administrator to filter routes in 2836 other EIGRP border routers based on this value. 2838 10.9.3.4 0x03 Community List 2839 This is used to provide communities for specific topology entries. It is not 2840 affected by K6 2842 0 1 2 3 2843 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 2844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2845 | 0x03 | Offset | Community List | 2846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2847 | (variable length) | 2848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2850 Offset Number of 16bit words in the sub-field. Currently transmitted as 4 2851 Community List One or more community values as defined in section 10.4 2853 10.9.3.5 0x04 Jitter 2854 0 1 2 3 2855 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 2856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2857 | 0x04 | 0x03 | Jitter | 2858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2859 | | 2860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2862 Jitter The measure of the variability over time of the latency across a 2863 network measured in measured in microseconds. 2865 Savage, et al. Expires August 16, 2015 [55] 2866 10.9.3.6 0x05 Quiescent Energy 2867 0 1 2 3 2868 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 2869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2870 | 0x05 | 0x02 | Q-Energy (high) | 2871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2872 | Q-Energy (low) | 2873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2875 Q-Energy - Paths with higher idle (standby) energy usage will be reflected in a 2876 higher aggregate metric than those having lower energy usage. If present, this 2877 number will represent the idle power consumption expressed in milliwatts per 2878 kilobit. 2880 10.9.3.7 0x06 Energy 2881 0 1 2 3 2882 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 2883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2884 | 0x06 | 0x02 | Energy (high) | 2885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2886 | Energy (low) | 2887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2889 Energy - Paths with higher active energy usage will be reflected in a higher 2890 aggregate metric than those having lower energy usage. If present, this number 2891 will represent the power consumption expressed in milliwatts per kilobit. 2893 10.9.3.8 0x07 AddPath 2894 The Add Path enables EIGRP to advertise multiple best paths to adjacencies. 2895 There will be up to a maximum of 4 AddPath supported, where the format of the 2896 field will be as follows; 2898 0 1 2 3 2899 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 2900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2901 | 0x07 | Offset | AddPath (Variable Length) | 2902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2904 Offset Number of 16bit words in the sub-field. Currently transmitted as 4 2906 AddPath Length of this field will vary in length based on weather it contains 2907 IPv4 or IPv6 data. 2909 10.9.3.8.1 Addpath with IPv4 Next-hop 2911 0 1 2 3 2912 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 2913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2914 | 0x07 | Offset | Next-hop Address(Upper 2 byes) | 2915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2916 | IPv4 Address (Lower 2 byes) | RID (Upper 2 byes) | 2917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2918 | RID (Upper 2 byes) | Admin Tag (Upper 2 byes) | 2919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2920 | Admin Tag (Upper 2 byes) |Extern Protocol| Flags Field | 2921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+ 2923 Savage, et al. Expires August 16, 2015 [56] 2924 Next Hop Address IPv4 address is represented by 4 8-bit values (total 4 2925 octets). If the value is zero(0), the IPv6 address from the received IPv4 2926 header is used as the next-hop for the route. Otherwise, the specified IPv4 2927 address will be used. 2929 Router Identifier (RID) A 32bit number provided by the router sourcing the 2930 information to uniquely identify it as the source. 2932 Admin Tag - A 32 bit administrative tag assigned by the network. This allows a 2933 network administrator to filter routes based on this value. 2935 If the route is of type external, then 2 addition bytes will be add as follows: 2937 External Protocol - Defines the external protocol that this route was learned. 2938 See Section 10.2 2940 Flag Field - See Section 10.8.1 2942 10.9.3.8.2 Addpath with IPv6 Next-hop 2943 0 1 2 3 2944 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 2945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2946 | 0x07 | Offset | Next-hop Address | 2947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2948 | | 2949 | (16 octets) | | 2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+| 2951 | | RID (Upper 2 byes) | 2952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2953 | RID (Upper 2 byes) | Admin Tag (Upper 2 byes) | 2954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+ 2955 | Admin Tag (Upper 2 byes) |Extern Protocol| Flags Field | 2956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+ 2958 Next Hop Address - IPv6 address is represented by 8 groups of 16-bit values 2959 (total 16 octets). If the value is zero(0), the IPv6 address from the received 2960 IPv6 header is used as the next-hop for the route. Otherwise, the specified IPv6 2961 address will be used. 2963 Router Identifier (RID) A 32bit number provided by the router sourcing the 2964 information to uniquely identify it as the source. 2966 Admin Tag - A 32 bit administrative tag assigned by the network. This allows a 2967 network administrator to filter routes based on this value. 2968 If the route is of type external, then 2 addition bytes will be add as follows: 2970 External Protocol - Defines the external protocol that this route was learned. 2971 See Section 10.2 2973 Flag Field - See Section 10.8.1 2975 Savage, et al. Expires August 16, 2015 [57] 2976 10.9.4 Exterior Encoding 2977 Additional routing information so provided for destinations outside of the EIGRP 2978 autonomous system as follows: 2979 0 1 2 3 2980 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 2981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2982 | Router Identification (RID) | 2983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2984 | Autonomous System Number (AS) | 2985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2986 | External Protocol Metric | 2987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2988 | Reserved |Extern Protocol| Flags Field | 2989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2991 Router Identifier (RID) A 32bit number provided by the router sourcing the 2992 information to uniquely identify it as the source. 2994 Autonomous System (AS) 32-bit number indicating the external autonomous system 2995 the sending router is a member of. If the source protocol is EIGRP, this field 2996 will be the [VRID|AS] pair. 2998 External Protocol Metric 32bit value of the metric used by the routing table 2999 as learned by the foreign protocol. If the External Protocol is IGRP or EIGRP, 3000 the value can (optionally) be 0, and the metric information is stored in the 3001 metric section. 3003 External Protocol - Defines the external protocol that this route was learned. 3004 See Section 10.2 3006 Flag Field - See Section 10.8.1 3008 10.9.5 Destination Encoding 3009 Destination information is encoded in Multi-Protocol packets in the same manner 3010 as used by Classic TLVs. This is accomplished by using a counter to indicate 3011 how many significant bits are present in the variable length address field 3012 0 1 2 3 3013 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 3014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3015 | Subnet Mask | Destination Address (variable length | 3016 | Bit Count | ((Bit Count - 1) / 8) + 1 | 3017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3019 Subnet Mask Bit Count 8-bit value used to indicate the number of bits in the 3020 subnet mask. A value of 0 indicates the default network and no address is 3021 present. 3023 Destination Address A variable length field used o carry the destination 3024 address. The length is determined by the number of consecutive bits in the 3025 destination address, rounded up to the nearest octet boundary, determines the 3026 length of the address. 3028 Savage, et al. Expires August 16, 2015 [58] 3029 10.9.6 Route Information 3031 10.9.6.1 INTERNAL TYPE 3032 This TLV conveys destination information based on the IANA AFI defined in the 3033 TLV Header (See Section 10.9.1), and associated metric information. Routes 3034 advertised in this TLV are network interfaces that EIGRP is configured on as 3035 well as networks that are learned via other routers running EIGRP. 3037 10.9.6.2 EXTERNAL TYPE 3038 This TLV conveys destination information based on the IANA AFI defined in the 3039 TLV Header (See Section 10.9.1), and metric information for routes learned by 3040 other routing protocols that EIGRP injects into the AS. Available with this 3041 information is the identity of the routing protocol that created the route, the 3042 external metric, the AS number, an indicator if it should be marked as part of 3043 the EIGRP AS, and a network administrator tag used for route filtering at EIGRP 3044 AS boundaries. 3046 Savage, et al. Expires August 16, 2015 [59] 3047 Author's Address 3049 Donnie V Savage 3050 Cisco Systems, Inc 3051 7025 Kit Creed Rd, RTP, NC 3053 Phone: 919-392-2379 3054 Email: dsavage@cisco.com 3056 Donald Slice 3057 Cumulus Networks 3058 Apex, NC 3060 Phone: 3061 Email: dslice@cumulusnetworks.com 3063 James Ng 3064 Cisco Systems, Inc 3065 7025 Kit Creed Rd, RTP, NC 3067 Phone: 919-392-2582 3068 Email: jamng@cisco.com 3070 Peter Paluch 3071 University of Zilina 3072 Univerzitna 8215/1, Zilina 01026, Slovakia 3074 Phone: 421-905-164432 3075 Email: Peter.Paluch@fri.uniza.sk 3077 Steven Moore 3078 Cisco Systems, Inc 3079 7025 Kit Creed Rd, RTP, NC 3081 Phone: 919-392-2674 3082 Email: smoore@cisco.com 3084 Russ White 3085 Ericsson 3086 Apex, NC 3088 Phone: 1-877-308-0993 3089 Email: russw@riw.us 3091 Savage, et al. Expires August 16, 2015 [60]