EIGRP is occasionally described as a distance vector protocol that acts like a link-state protocol.
Compared to distance vector protocols, link-state protocols are far less susceptible to routing loops and bad routing information. The forwarding of link-state packets is not dependent on performing the route calculations first, so large networks might converge faster. And only links or prefixes and their states are advertised, not routes, which means the change of a link will not cause the advertisement of all routes using that link.
Although EIGRP updates are still vectors of distances transmitted to directly connected neighbors, they are nonperiodic, partial, and bounded. Nonperiodic means that updates are not sent at regular intervals; rather, updates are sent only when a metric or topology change occurs. Partial means that the updates will include only routes that have changed, not every entry in the route table.
Bounded means that the updates are sent only to affected routers. These characteristics mean that EIGRP uses much less bandwidth than typical distance vector protocols use. This feature can be especially important on low-bandwidth, high-cost Wide Area Network (WAN) links.
Another concern when routing over low-bandwidth WAN links is the maximum amount of bandwidth used during periods of convergence, when routing traffic is high. By default, EIGRP uses no more than 50 percent of the bandwidth of a link. Later IOS releases allow this percentage to be changed with the command ip bandwidth-percent eigrp.
EIGRP is a classless protocol (that is, each route entry in an update includes a subnet mask).
EIGRP uses the same formula that IGRP uses to calculate its composite metric. However, EIGRP scales the metric components by 256 to achieve a finer metric granularity. So if the minimum configured bandwidth on the path to a destination is 512K and the total configured delay is 46000 microseconds, IGRP would calculate a composite metric of 24131. EIGRP, however, will multiply the bandwidth and delay components by 256 for a metric of 256 x 24131 = 6177536.
EIGRP has four components :
- • Protocol-Dependent Modules
- • Reliable Transport Protocol (RTP)
- • Neighbor Discovery/Recovery
- • Diffusing Update Algorithm (DUAL)
EIGRP implements modules for IP, IPX, and AppleTalk, which are responsible for the protocol-specific routing tasks. For example, the IPX EIGRP module is responsible for exchanging route information about IPX networks with other IPX EIGRP processes and for passing the information to the DUAL.
Reliable Transport Protocol
The Reliable Transport Protocol (RTP) manages the delivery and reception of EIGRP packets. Reliable delivery means that delivery is guaranteed and that packets will be delivered in order.
Guaranteed delivery is accomplished by means of a Cisco-proprietary algorithm known as reliable multicast, using the reserved class D address 184.108.40.206. Each neighbor receiving a reliably multicast packet unicasts an acknowledgment.
Ordered delivery is ensured by including two sequence numbers in the packet. Each packet includes a sequence number assigned by the sending router. This sequence number is incremented by one each time the router sends a new packet. In addition, the sending router places in the packet the sequence number of the last packet received from the destination router.
In some cases, RTP may use unreliable delivery. No acknowledgment is required, and no sequence number will be included for unreliably delivered EIGRP packets.
EIGRP uses multiple packet types, all of which are identified by protocol number 88 in the IP header:
- • Hellos are used by the neighbor discovery and recovery process. Hello packets are multicast and use unreliable delivery.
- • Acknowledgments (ACKs) are Hello packets with no data in them. ACKs are always unicast and use unreliable delivery.
- • Updates convey route information. Unlike RIP and IGRP updates, these packets are transmitted only when necessary, contain only necessary information, and are sent only to routers that require the information. When updates are required by a specific router, they are unicast. When updates are required by multiple routers, such as upon a metric or topology change, they are multicast. Updates always use reliable delivery.
- • Queries and Replies are used by the DUAL finite state machine to manage its diffusing computations. Queries can be multicast or unicast, and replies are always unicast. Both queries and replies use reliable delivery.
- • Requests were a type of packet originally intended for use in route servers. This application was never implemented, and request packets are noted here only because they are mentioned in some older EIGRP documentation.
If any packet is reliably multicast and an ACK is not received from a neighbor, the packet will be retransmitted as a unicast to that unresponding neighbor. If an ACK is not received after 16 of these unicast retransmissions, the neighbor will be declared dead.
The time to wait for an ACK before switching from multicast to unicast is specified by the multicast flow timer. The time between the subsequent unicasts is specified by the retransmission timeout (RTO). Both the multicast flow timer and the RTO are calculated for each neighbor from the smooth round-trip time (SRTT).
The SRTT is the average elapsed time, measured in milliseconds, between the transmission of a packet to the neighbor and the receipt of an acknowledgment. The formulas for calculating the exact values of the SRTT, the RTO, and the multicast flow timer are proprietary.
Because EIGRP updates are nonperiodic, it is especially important to have a process whereby neighborsEIGRP-speaking routers on directly connected networksare discovered and tracked. On most networks, Hellos are multicast every five seconds, minus a small random time to prevent synchronization. On multipoint X.25, Frame Relay, and ATM interfaces, with access link speeds of T1 or slower, Hellos are unicast every 60 seconds. This longer Hello interval is also the default for ATM SVCs and for ISDN PRI interfaces.
In all cases, the Hellos are unacknowledged. The default Hello interval can be changed on a per interface basis with the command ip hello-interval eigrp.
Point-to-point subinterfaces send Hellos every 5 seconds. When a router receives a Hello packet from a neighbor, the packet will include a hold time. The hold time tells the router the maximum time it should wait to receive subsequent Hellos. If the hold timer expires before a Hello is received, the neighbor is declared unreachable and DUAL is informed of the loss of a neighbor. By default, the hold time is three times the Hello interval180 seconds for low-speed nonbroadcast multiaccess (NBMA) networks and 15 seconds for all other networks. The default can be changed on a per interface basis with the command ip hold-time eigrp. The capability to detect a lost neighbor within 15 seconds, as opposed to 180 seconds for RIP and 270 seconds for IGRP, is one factor contributing to EIGRP’s fast reconvergence. Information about each neighbor is recorded in a neighbor table.
Diffusing Update Algorithm
DUAL is a convergence algorithm that replaces the Bellman-Ford or Ford-Fulkerson algorithms used by other distance vector protocols. The design philosophy behind DUAL is that even temporary routing loops are detrimental to the performance of a network. DUAL uses diffusing computations, first proposed by E. W. Dijkstra and C. S. Scholten, to perform distributed shortest-path routing while maintaining freedom from loops at every instant. Although many researchers have contributed to the development of DUAL, the most prominent work is that of J. J. Garcia-Luna-Aceves.
Before the operation of DUAL can be examined, a few terms and concepts must be described.
Upon startup, a router uses Hellos to discover neighbors and to identify itself to neighbors. When a neighbor is discovered, EIGRP will attempt to form an adjacency with that neighbor. An adjacency is a logical association between two neighbors over which route information is exchanged. When adjacencies have been established, the router will receive updates from its neighbors. The updates will contain all routes known by the sending routers and the metrics of those routes. For each route, the router will calculate a distance based on the distance advertised by the neighbor and the cost of the link to that neighbor.
The lowest calculated metric to each destination will become the feasible distance (FD) of that destination. For example, a router may be informed of three different routes to subnet 172.16.5.0 and may calculate metrics of 380672, 12381440, and 660868 for the three routes. 380672 will become the FD because it is the lowest calculated distance.
The feasibility condition (FC) is a condition that is met if a neighbor’s advertised distance to a destination is lower than the router’s FD to that same destination.
If a neighbor’s advertised distance to a destination meets the FC, the neighbor becomes a feasible successor for that destination.
Every destination for which one or more feasible successors exist will be recorded in a topological table, along with the following items:
- • The destination’s FD
- • All feasible successors
- • Each feasible successor’s advertised distance to the destination
- • The locally calculated distance to the destination via each feasible successor, based on the feasible successor’s advertised distance and the cost of the link to that successor
- • The interface connected to the network on which each feasible successor is found.
For every destination listed in the topological table, the route with the lowest metric is chosen and placed into the route table. The neighbor advertising that route becomes the successor, or the next-hop router to which packets for that destination are sent.
EIGRP Packet Formats
The IP header of an EIGRP packet specifies protocol number 88, and the maximum length of the packet will be the IP maximum transmission unit (MTU) of the interface on which it is transmittedusually 1500 octets. Following the IP header is an EIGRP header followed by various Type/Length/Value (TLV) triplets. These TLVs will not only carry the route entries but also may provide fields for the management of the DUAL process, multicast sequencing, and IOS software versions.
EIGRP Packet Header
- • Version— Specifies different versions of EIGRP. Version 2 of EIGRP was implemented beginning with Cisco IOS Software Releases 10.3(11).
- • Opcode— Specifies the types of EIGRP packet contained. Opcode 1 is the update packet, opcode 3 is the Query, opcode 4 is the reply, and opcode 5 is the EIGRP hello packet.
- • Checksum— Used as the regular IP checksum, calculated based on the entire EIGRP packet, excluding the IP header.
- • Flags— Involves only two flags now. The flag indicates either an init for new neighbor relationship or the conditional receive for EIGRP RTP.
- • Sequence— Specifies the sequence number used by the EIGRP RTP.
- • Acknowledgment— Used to acknowledge the receipt of an EIGRP reliable packet.
- • Autonomous System Number— Specifies the number for the identification of EIGRP network range.
General TLV Fields
These TLVs carry EIGRP management information and are not specific to any one routed protocol. The Parameters TLV, which is used to convey metric weights and the hold time.
EIGRP IP Internal Route TLV
EIGRP IP External Route TLV
Unlike IGRP, EIGRP is an advanced distance vector protocol that carries the subnet mask information when an update is sent out. Therefore, EIGRP supports discontiguous network and variable-length subnet masking (VLSM).
Two types of summarization take place in EIGRP—autosummarization and manual summarization. Autosummarization is the default behavior for EIGRP, just as it is for RIP and IGRP. Basically, when the router sends out a routing update, it automatically summarizes the route to its natural major network when the route is advertised across a major network boundary.
Figure shows an example of autosummarization. In Figure Router R1 needs to send an update about the network 220.127.116.11 to R2 across a major network of 192.168.2.0. R1 then autosummarizes the update to its classful network of 18.104.22.168 and sends it to R2. The problem of autosummarization is that the design of the network cannot be discontiguous.
For example, Router R1 needs to send an update about the network 22.214.171.124 to R2 across a major network of 192.168.2.0. R1 then autosummarizes the update to its classful network of 126.96.36.199 and sends it to R2. The problem of autosummarization is that the design of the network cannot be discontiguous.
Manual summarization in EIGRP is configurable on a per-interface basis in any router within the network. The command for EIGRP manual summarization is ip summary-address eigrp autonomous-system-number address mask. With EIGRP, summarization can be done on any interface and any router in the network, compared to OSPF, which can summarize only on an area border router (ABR) and an autonomous system border router (ASBR). When manual summarization is configured on the interface, the router will immediately create a route to null 0 with an administrative distance of 5. This is to prevent routing loops of summary address. Finally, when the last specific route of the summary goes away, the summary route is deleted.
EIGRP Manual Summarization Example
Configuring EIGRP Manual Summarization
ip address 192.168.11.1 255.255.255.252
ip summary-address eigrp 1 192.168.8.0 255.255.252.0
Example demonstrates how R1 is summarizing addresses of 192.168.8.0/24, 192.168.9.0/24, and 192.168.10.0/24 into one update of 192.168.8.0/22. Summarization in EIGRP reduces the size of the routing table and the number of updates. It also limits the query range, which is crucial in terms of making a large EIGRP network more stable and more scalable.
EIGRP Query Process
Although EIGRP is an advanced distance vector routing protocol and convergence time is low, an EIGRP router still relies on its neighbor to advertise routing information. To achieve fast convergence, EIGRP can’t rely on a flush timer like IGRP. EIGRP needs to actively search for the lost routes for fast convergence. This process is called the query process.
At this stage, the route is said to be in the Active state.
Queries are sent out to all the neighbors and on all interfaces except for the interface to the successor. If the neighboring routers do not have the lost route information, more queries are sent to the neighboring routers’ neighbors until the query boundary is reached. Query boundary consists of either the end of the network, the distribute list boundary, or the summarization boundary.
If any neighbor fails to reply in three minutes, the route is said to be stuck in active (SIA), and the neighbor relationship of the router that didn’t reply to the query is reset.
Default Routes and EIGRP
EIGRP recognizes the 0.0.0.0/0 route as the default route and allows it to be redistributed into EIGRP domain as the default route. EIGRP also uses its own method of propagating the default route with the ip default-network command.
The ip default-network command specifies a major network address and flags it as a default network. This major network could be directly connected, defined by a static route, or discovered by a dynamic routing protocol.
Unequal-Cost Load Balancing in EIGRP
EIGRP and IGRP use the same equation to calculate their metrics, and they share the same behavior when it comes to unequal-cost load balancing. EIGRP also can install up to six parallel equal-cost paths for load balancing, like IGRP can, and EIGRP also uses the same variance command as IGRP to do unequal-cost path load balancing.
Unequal-Cost Load Balancing Example
Remember the rules for multipath operation:
- • The neighboring router utilized as an alternate pathway must be closer to the destination (that is, it must be advertising a smaller metric than that of the local router for a given destination). It’s not possible to go back to go forward.
- • The metric advertised by the neighbor must be less than the variance of the local router’s metric. Variance = Variance Factor 3 Local Metric.
To use the unequal-cost load-balancing feature of EIGRP, you use the variance command. Variance is a multiplier in which a metric may be different from the lowest metric to a route. The variance value must be of integer value; the default variance value is 1, meaning that the metrics of multiple routes must be equal to load-balance.
In last example the metric through the 256 kbps link is 4.8 times larger than the metric through the 1544 kbps link. Therefore, for the 256 kbps link to be considered in the routing table, a variance of 5 must be configured in Router 1. The configuration in Router 1 is simply variance 5 under the router eigrp command.
Setting Maximum Paths
The maximum number of routes over which EIGRP can load balance is set with the maximum-paths paths command. paths may be any number from 1 to 16 in IOS 12.3(2)T and later 12.3(T) releases and any number from 1 to 6 in earlier versions. The default for all versions is 4.
When an entry in a router’s EIGRP topology table changes for the worse (either the metric increases, or the successor is no longer accessible), if there is no feasible successor for the address, the entry goes into Active state, and the router sends query packets to all its neighbors.
A router that has EIGRP Stub neighbors will not send queries to the stubs, thereby eliminating the chance that a stub-configured remote site will cause stuck in active conditions, and routing instabilities in other parts of the network.
EIGRP stub router configuration.
router eigrp 15
EIGRP Error Messages
Some EIGRP error messages that occur in the log have mystified many network administrators.
- • DUAL-3-SIA— This message means that the primary route is gone and no feasible successor is available. The router has sent out the queries to its neighbor and has not heard the reply from a particular neighbor for more than three minutes.
- • Neighbor not on common subnet— This message means that the router has heard a hello packet from a neighbor that is not on the same subnet as the router.
- • DUAL-3-BADCOUNT— Badcount means that EIGRP believes that it knows of more routes for a given network than actually exist. It’s typically (not always) seen in conjunction with DUAL-3-SIAs, but it is not believed to cause any problems by itself.
- • Unequal, <route>, dndb=<metric>, query=<metric>— This message is informa-tional only. It says that the metric the router had at the time of the query does not match the metric that it had when it received the reply.
- • DUAL-3-INTERNAL: IP-EIGRP Internal Error— This message indicates that there is an EIGRP internal error. However, the router is coded to fully recover from this internal error. The EIGRP internal error is caused by software problem and should not affect the operation of the router.
- • IP-EIGRP: Callback: callbackup_routes— At some point, EIGRP attempted to install routes to the destinations and failed, most commonly because of the existence of a route with a better administrative distance. When this occurs, EIGRP registers its route as a backup route. When the better route disappears from the routing table, EIGRP is called back through callbackup_routes so that it can attempt to reinstall the routes that it is holding in the topology table.
- • Error EIGRP: DDB not configured on interface— This means that when the router’s interface receives an EIGRP hello packet and the router goes to associate the packet with a DDB (DUAL descriptor block) for that interface, it does not find one that matches. This means that the router is receiving a hello packet on the interface in which doesn’t have EIGRP configured.
- • Poison squashed— The router threads a topology table entry as a poison in reply to an update (the router set up for poison reverse). While the router is building the packet that contains the poison reverse, the router realizes that it doesn’t need to send it.
MD5 cryptographic checksums are the only authentication supported in EIGRP, which on first consideration might seem less flexible than RIPv2 and OSPF, which support both MD5 and clear-text passwords. However, clear-text password authentication should be used only when a neighboring device does not support the more secure MD5. Because EIGRP will be spoken only between two Cisco devices, this situation will never arise.
The steps for configuring EIGRP authentication are:
Step 1. Define a key chain with a name.
Step 2. Define the key or keys on the key chain.
Step 3. Enable authentication on an interface and specify the key chain to be used.
Step 4. Optionally configure key management.
key chain Edwards
ip address 172.20.15.6 255.255.255.252
ip authentication key-chain eigrp 15 Edwards
ip authentication mode eigrp 15 md5
Optional : Send-time & accept-time
When a route goes active and queries are sent to neighbors, the route will remain active until a reply is received for every query. But what happens if a neighbor is dead or otherwise incapacitated and cannot reply? The route would stay permanently active. The active timer and SIA-retransmit timer are designed to prevent this situation. Both the active timer and the SIA-retransmit timer are set when a query is sent.
Source : http://www.cisco.com, cisco BSCI student guide