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