EIGRP History
Before EIGRP hit our scenes we had IGRP, Interior Gatway Routing Protocol.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. IGRP calculated a composite metric from a variety of route variables and provided “knobs” for weighting the variables to reflect the specific characteristics and needs of the network. 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.
Advantages that IGRP presented over RIP;
- Unequal-cost load sharing
- An update period three times longer than RIP’s
- A more efficient update packet format
IGRP was created with the idea of being able to work in more versatile networks, by not only working with the IP protocol it was made to work with many other routed protocols like, ISO Connectionless Network Protocol (CLNP). EIGRP has taken on this feature and it too can route other protocols like, IP, IPX and Apple Talk.
Like RIP, IGRP broadcasts a request packet out all IGRP-enabled interfaces upon startup and performs a sanity check on received updates to verify that the source address of the packet belongs to the same subnet on which the update was received.
IGRP was also like RIP because it to was a classful distance vector protocol that periodically broadcasts its entire routing table. Split horizon with poisoned reverse, triggered updates, and holddown timers are used for stability; IGRP also summarizes addresses at network boundaries too.
Unlike RIP, which is accessed via UDP, the IGRP process is accessed directly from the IP layer as protocol 9.
IGRP was developed with the idea of running Process Domains. A Process Domain helps in been able to devied you network in different sections and keeping apart different routing domains. Traffic between the domains can then be closely regulated by redistribution.
IGRP classifies route entries into one of three categories: interior routes, system routes, and exterior routes;
- Interior route is a path to a subnet of the network address of the data link on which the update is being broadcast. In other words, a subnet advertised as an interior route is “local” to the major network to which the advertising router and the receiving router are commonly connected.
- System route is a path to a network address, which has been summarized by a network boundary router.
- Exterior route is a path to a network that has been flagged as a default network. A default network is an address to which a router will send any packet that cannot be matched to a more specific destination.
Timers
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 2 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 holddown may be disabled with the command no metric holddown. In loop-free topologies, where holddown has no real benefit, disabling the function can reduce reconvergence time.
Sleeptime is a timer used to specify a period, in milliseconds, to delay a regular routing update after receiving a triggered update.
The default timers can be changed with the following command;
Router(config-router)#timers basic ?
<0-4294967295> Interval between updates
Router(config-router)#timers basic 30 ?
<1-4294967295> Invalid
Router(config-router)#timers basic 30 60 ?
<0-4294967295> Holddown
Router(config-router)#timers basic 30 60 120
Metrics
The link characteristics from which IGRP, and also EIGRP, calculates its composite metric are bandwidth, delay, load, and reliability. By default, IGRP and EIGRP chooses a route based onbandwidth 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. Load and reliability are taken into consideration only if the router is configured to do so. IGRP and EIGRP also tracks the smallest Maximum Transmission Unit (MTU) along each route, although the MTU is not used in the composite metric calculation.
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. The bandwidth number may be changed from the default with the bandwidth command.
Router(config-if)#bandwidth ?
<1-10000000> Bandwidth in kilobits
inherit Specify that bandwidth is inherited
receive Specify receive-side bandwidth
Router(config-if)#bandwidth 30000
To calculate the bandwidth the following formal is used;
BW = 107/ {Interface Bandwidth} = EIGRP Bandwidth cost.
So if we take the bandwidth we have configured on the interface, 30000Kb, and use the formal we will work out what EIGRP will calculate the interface bandwidth at;
107/ 30000 = 333
Delay, like bandwidth, is a static figure and is not measured dynamically. The default delay of an interface may be changed with the delay command, which specifies the delay in tens of microseconds.
Router(config-if)#delay ? <1-16777215> Throughput delay (tens of microseconds)
Router(config-if)#delay 25000
To calculate the delay on an interface, the following formal is used;
DLY = {Interface Delay}/10 = EIGRP Delay
So if we take the delay we have configured on the interface, 25000 microseconds, and use the formal we will work out what EIGRP will calculate the interface delay at;
25000/10 = 2500
IGRP uses bandwidth and delay as its default metrics, these quantities must be configured correctly and consistently on all interfaces of all IGRP routers.
It is important to note that OSPF also uses the bandwidth statement to calculate its metric. Therefore if EIGRP metrics are to be manipulated in a network where OSPF is also running, use the delay to influence EIGRP. Changing the bandwidth will affect both EIGRP and OSPF.
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.
Load is represented as a fraction of 255, 1 is a minimally loaded link, and 255 is a 100 percent loaded link.
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. If an 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 EIGRP route is calculated as;
metric = [k1*BW(min) + (k2* BW(min))/(256-LOAD) + k3*DLY(sum)] x [k5/(RELIABILITY + k4)]
Where BW(min) is the minimum BW of all the outgoing interfaces along the route to the destination and DLY(sum) is the total DLY of the route.
The values k1 through k5 are configurable weights; their default values are k1=1 k2=0 k3=1 k4= 0 k5=0. (K1 = Bandwidth K2 = Load K3 = Delay K4 = Reliability K5 = MTU)
These defaults can be changed with the command:
Router(config-router)#metric weights ?
<0-8> Type Of Service (Only TOS 0 supported)
Router(config-router)#metric weights 0 ?
<0-255> K1
Router(config-router)#metric weights 0 1 ?
<0-255> K2
Rack1R1(config-router)#metric weights 0 1 1 ?
<0-255> K3
Router(config-router)#metric weights 0 1 1 0 ?
<0-255> K4
Router(config-router)#metric weights 0 1 1 0 0 ?
<0-255> K5
Router(config-router)#metric weights 0 1 1 0 0 1
EIGRP
As we can see IGRP has got it draw backs as follows;
- Sending full periodic routing updates
- A hop limitation
- The lack of VLSM support
- Slow convergence
- The lack of loop prevention mechanisms
So to over come these draw backs Cisco set about and developed a “Enhanced” version of the IGRP. Since IGRP did make a distance vector routing protocols, RIP, a lot better, it could still be made to work even better. So by coming up with EIGRP (Enhanced Interior Gateway Routing Protocol). EIGRP carried over a lot of the good things about IGRP but also brought some of its own cool stuff.
Unlike the traditional Distance Vector routing protocols which will send their neighbors period routing updates that contain all routing information, EIGRP sends non-periodic incremental routing updates to distribute routing information throughout the routing domain. The EIGRP incremental updates are sent when there is a change in the network topology. EIGRP has a default hop-count limitation of 100; however, this value can be manually adjusted by the administrator using the following command;
Router(config-router)#metric maximum-hops ?
<1-255> Hop count
EIGRP uses two unique Type/Length/Value (TLV) triplets to carry route entries. These TLVs are the Internal EIGRP Route TLV and External EIGRP Route TLV. Both TLVs include an 8-bit Prefix Length field which specifies the number of bits used for the subnet mask of the destination network. The information that is contained in this field allows EIGRP to support variably subnetted networks.
EIGRP internal and external routes can be distinguished between in routing table by the AD (Admin Distance). Internal have AD of 90 by default and External have an AD of 170 by default. These can be changed under the routing protocol with the following command;
Router(config-router)#distance eigrp ?
<1-255> Distance for internal routes
Router(config-router)#distance eigrp 90 ?
<1-255> Distance for external routes
Router(config-router)#distance eigrp 90 100
EIGRP converges much faster than the traditional Distance Vector routing protocols. Instead of relying solely on timers, EIGRP uses information contained in its Topology Table to locate alternate paths. EIGRP can also query neighboring routers for information to an alternate path if it is not located in the local routers Topology Table.
In order to ensure that there are loop-free paths through the network, EIGRP uses the Diffusing Update Algorithm (DUAL). DUAL is used to track all routes advertised by neighbors and then select the best, loop-free path to the destination network.
One last thing EIGRP has which gives it that extra edge is something called PDM (Protocol Dependent Modules). This is defiantly an enhancement to something IGRP already had. PDMs are responsible for Network Layer (Layer 3) protocol-specific requirements, such as IP, IPX and AppleTalk. This means that if you are running IP EIGRP, IPX EIGRP and AppleTalk EIGRP, there will be three different EIGRP Neighbor Tables: one for the IP EIGRP neighbors, another for the IPX EIGRP neighbors and the third one for the AppleTalk EIGRP neighbors. Using the IP PDM, IP EIGRP asks DUAL to make routing decisions. IP EIGRP is responsible for redistributing routes learned by other IP routing protocols. This information is then stored in the EIGRP Topology Table.
Now after looking at a quick overview of what “Enhancements” EIGRP has over other Distance Vector routing protocols, its time to look deeper into these “Enhancements”.