Quick Notes: EIGRP Basics

** From: Routing TCP/IP, Volume I, 2nd Edition **

The Roots of EIGRP: An Overview of IGRP

Like IGRP, EIGRP is a distance vector protocol and uses the same composite metrics as IGRP uses. Beyond that, there are few similarities.
Cisco developed IGRP in the mid-1980s as an answer to the limitations of RIP, the most significant of which are the hop count metric and the 15-hop network size.
Although hop count is not one of these variables, IGRP did track hop count, and could be implemented on networks of up to 255 hops in diameter.
The other advantages that IGRP presented over RIP are

Unequal-cost load sharing
An update period three times longer than RIP’s
A more efficient update packet format

The chief disadvantage of both IGRP and EIGRP is that they are proprietary to Cisco.
It is a classful distance vector protocol that periodically broadcasts its entire routing table—with the exception of routes suppressed by split horizon—to all its neighbors.
Split horizon with poisoned reverse, triggered updates, and holddown timers are used for stability; IGRP summarizes addresses at network boundaries.
Unlike RIP, which is accessed via UDP, the IGRP process is accessed directly from the IP layer as protocol 9.

IGRP Timers and Stability Features

The IGRP update period is 90 seconds.
A random jitter variable of up to 20 percent is subtracted from each update time to prevent update timer synchronization, so the time elapsed between individual updates will vary from 72 to 90 seconds.
When a route is first learned, the invalid timer for that route is set for 270 seconds, or three times the update period.
The flush timer is set for 630 seconds—seven times the update period.
Each time an update is received for the route, these timers are reinitialized.
If the invalid timer expires before an update is heard, the route is marked as unreachable.
It will be held in the routing table and advertised as unreachable until the flush timer expires, at which time the route will be deleted from the table.
If a destination becomes unreachable or if the next-hop router increases the metric of a destination enough to cause a triggered update, the route will be placed in holddown for 280 seconds (three update periods plus 10 seconds).
Until the holddown timer expires, no new information will be accepted about this destination.

IGRP Metrics

Most significant change from RIP to IGRP is the use of multiple metric parameters, based on link characteristics.
The link characteristics from which IGRP calculates its composite metric are bandwidth, delay, load, and reliability.
By default, IGRP chooses a route based on bandwidth and delay.
If a data link is thought of as a pipe, then bandwidth is the width of the pipe and delay is the length of the pipe.
In other words, bandwidth is a measure of the carrying capacity, and delay is a measure of the end-to-end travel time.
Load and reliability are taken into consideration only if the router is configured to do so.
IGRP also tracks the smallest Maximum Transmission Unit (MTU) along each route, although the MTU is not used in the composite metric calculation.
The quantities associated with IGRP’s composite metric on a specific interface can be observed with the show interfaces command.

Newfoundland#show interfaces ethernet 0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c76.5b7c (bia 0000.0c76.5b7c)
Internet address is 10.2.1.2/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:07, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
601753 packets input, 113607697 bytes, 0 no buffer
Received 601753 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
693494 packets output, 557731861 bytes, 0 underruns
0 output errors, 5 collisions, 13 interface resets
0 babbles, 0 late collision, 48 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Newfoundland#

This Ethernet interface shows MTU = 1500 bytes, bandwidth = 10 megabits per second, delay = 1000 microseconds, reliability = 100 percent, and load = 0.39 percent (minimum load).
Bandwidth is expressed in units of kilobits per second. It is a static number used for metric calculation only and does not necessarily reflect the actual bandwidth of the link.
This bandwidth number may be changed from the default with the bandwidth command.
IGRP updates use a three-octet number, referred to in this book as BW_IGRP, which is the inverse of the bandwidth scaled by a factor of 10^7. If the bandwidth of an interface is 1544, then BW_IGRP = 10^7/1544 = 6476, or 0x00194C.
Delay, like bandwidth, is a static figure, and displayed in units of microseconds.
The default delay of an interface may be changed with the delay command, which specifies the delay in tens of microseconds.

Newfoundland(config)#interface e0
Newfoundland(config-if)#bandwidth 75000
Newfoundland(config-if)#delay 5

Newfoundland#show interfaces ethernet0
Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c76.5b7c (bia 0000.0c76.5b7c)
Internet address is 10.2.1.2/24
MTU 1500 bytes, BW 75000 Kbit, DLY 50 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:02, output 00:00:02, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
601888 packets input, 113637882 bytes, 0 no buffer
Received 601888 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
693646 packets output, 557884632 bytes, 0 underruns
0 output errors, 5 collisions, 13 interface resets
0 babbles, 0 late collision, 48 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Newfoundland#

When carried in an IGRP update, delay is a three-octet number expressed in the same 10-microsecond units as specified by the delay command.
If DLY is 50, then DLY_IGRP = DLY/10 = 50/10 = 5, or 0x000005.
IGRP also uses delay to indicate an unreachable route by setting DLY_IGRP = 0xFFFFFF. This number translates to approximately 167.8 seconds, so the maximum end-to-end delay of an IGRP route is 167 seconds.
If IGRP (or EIGRP) metrics are to be manipulated in a network, use the delay.
Reliability is measured dynamically and is expressed as an eight-bit number, where 255 is a 100 percent reliable link and 1 is a minimally reliable link. In the output of show interface, reliability is shown as a fraction of 255, for example, 234/255. This interface shows a reliability of 234/255, or 91.8 percent.
Load, in an IGRP update, is an eight-bit number. Load is represented in the output of show interface as a fraction of 255, such as 40/255; 1 is a minimally loaded link, and 255 is a 100 percent loaded link. This interface shows a load of 40/255, or 15.7 percent.
If reliability or load is to be used as a metric or as part of a composite metric, the algorithm for calculating the metric must not allow sudden changes in the error rate or channel occupancy to destabilize the network. As an example, if a “raw,” or instantaneous, measure of load is used, a burst of heavy traffic could cause a route to go into holddown and an abrupt drop in traffic could trigger an update. To prevent frequent metric changes, reliability and load are calculated based on an exponentially weighted average with a five-minute time constant, which is updated every five seconds.

The composite metric for each IGRP route is calculated as

metric = [k1*BW_IGRP(min) + (k2* BW_IGRP(min))/(256-LOAD) + k3*DLY_IGRP(sum)] × [k5/(RELIABILITY + k4)],

where BW_IGRP(min) is the minimum BW_IGRP of all the outgoing interfaces along the route to the destination and DLY_IGRP(sum) is the total DLY_IGRP of the route.

The values k1 through k5 are configurable weights; their default values are k1=k3=1 and k2=k4=k5=0. These defaults can be changed with the command metric weights tos k1 k2 k3 k4 k5.
Given the default values for k1 through k5, the composite metric calculation used by IGRP reduces to the default metric: metric = BW_IGRP(min) + DLY_IGRP(sum).
The routing table itself shows only the derived metric, but the actual variables recorded by IGRP for each route can be seen by using the command show ip route address.

Casablanca#show ip route 172.20.40.0
Routing entry for 172.20.40.0 255.255.255.0
Known via "igrp 1", distance 100, metric 24131
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 172.20.1.2 on Ethernet0, 00:00:54 ago
Routing Descriptor Blocks:
* 172.20.1.2, from 172.20.1.2, 00:00:54 ago, via Ethernet0
Route metric is 24131, traffic share count is 1
Total delay is 46000 microseconds, minimum bandwidth is 512 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2

IGRP also records the smallest MTU along the route in addition to the hop count. MTU is not used in the metric calculation. Hop count is the hop count reported by the next-hop router and is used only to limit the diameter of the network.
By default, the maximum hop count is 100 and can be configured from 1 to 255 with the command metric maximum-hops.
If the maximum hop count is exceeded, the route will be marked unreachable by setting the delay to 0xFFFFFF.
Note that all metrics are calculated from the outgoing interfaces along the route.

From IGRP to EIGRP

The original motivation for developing EIGRP was simply to make IGRP classless.
A new kind of convergence algorithm was also introduced.
The result was a protocol that, while retaining some concepts introduced with IGRP such as multiple metrics, protocol domains, and unequal-cost load balancing, is distinctly different from IGRP.
EIGRP is occasionally described as a distance vector protocol that acts like a link-state protocol.
A distance vector protocol shares everything it knows, but only with directly connected neighbors. Link-state protocols announce information only about their directly connected links, but they share the information with all routers in their routing domain or area.
All the distance vector protocols discussed so far run some variant of the Bellman-Ford (or Ford-Fulkerson) algorithm. These protocols are prone to routing loops and counting to infinity. As a result, they must implement loop-avoidance measures such as split horizon, route poisoning, and hold-down timers.
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.
In contrast to the Bellman-Ford algorithms used by most other distance vector protocols, EIGRP uses a system of diffusing computations—route calculations that are performed in a coordinated fashion among multiple routers—to attain fast convergence while remaining loop-free at every instant.
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.
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 packets can be authenticated using an MD5 cryptographic checksum.

Operation of EIGRP

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 × 24131 = 6177536.
IP EIGRP automatically redistributes routes with IGRP if the IGRP process is in the same autonomous system.

Reliable Transport Protocol (RTP)

The Reliable Transport Protocol (RTP) manages the delivery and reception of EIGRP packets.
Reliable means that the delivery is guaranteed and that packets area delivered in order.
Guaranteed delivery is accomplished by means of a Cisco-proprietary algorithm known as reliable multicast, using the reserved class D address 224.0.0.10.
Each neighbor receiving a reliably multicast packet unicasts an acknowledgment.
Ordered delivery is ensured by including two sequence numbers in the packet.

A sequence number incremented by one with every new 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.

Neighbor Discovery/Recovery

Because EIGRP updates are nonperiodic, it is especially important to discover and track neighbors.
On most networks, Hellos are multicast every five seconds, minus a small random time to prevent synchronization.
With access link speeds of T1 or slower, Hellos are unicast every 60 seconds.
In all cases, the Hellos are unacknowledged.
The default Hello interval can be changed on a per interface basis with the ip hello-interval eigrp command.
The Hello packet includes 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 interval—180 seconds for low-speed nonbroadcast multiaccess (NBMA) networks and 15 seconds for all other networks.
The default hold time can be changed on a per interface basis with the ip hold-time eigrp command.
Information about each neighbor is recorded in a neighbor table.
The neighbor table records the IP address of the neighbor and the interface on which the neighbor’s Hellos are received.
The hold time advertised by the neighbor is recorded, as is the SRTT and the uptime—the time since the neighbor was added to the table. The RTO is the time, in milliseconds, that the router will wait for an acknowledgment of a unicast packet sent after a multicast has failed.
The Q Count indicates the number of enqueued packets.
The sequence number of the last update, query, or reply packet received from the neighbor is also recorded in the neighbor table. The RTP tracks these sequence numbers to ensure that packets from the neighbor are not received out of order.
The H column records the order in which the neighbors were learned.
The show ip eigrp neighbors command is used to observe the IP EIGRP neighbor table.

Wright#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
3 10.1.1.2 Et0 10 09:01:27 12 200 0 5
2 10.1.4.2 Se1 13 09:02:11 23 200 0 11
1 10.1.2.2 Et1 14 09:02:12 8 200 0 15
0 10.1.3.2 Se0 12 09:02:12 21 200 0 13
Wright#

Network Playroom

Search This Blog