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