Skip this Video
Download Presentation
Configuring EIGRP

Loading in 2 Seconds...

play fullscreen
1 / 88

Configuring EIGRP - PowerPoint PPT Presentation

  • Uploaded on

Configuring EIGRP. Andrei Bot. April 5 th , 2012. Introduction to EIGRP Concepts EIGRP Basic configuration EIGRP traffic engineering EIGRP filtering. EIGRP concepts. Introduction

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Configuring EIGRP' - bandele

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Configuring EIGRP

Andrei Bot

April 5th, 2012


Introduction to EIGRP Concepts

EIGRP Basic configuration

EIGRP traffic engineering

EIGRP filtering



First released in IOS 9.21, EIGRP(Enhanced Interior Gateway Routing Protocol) is as the name says, an enhancement of the Cisco IGRP(Interior Gateway Routing Protocol)

Unlike RIP and RIPv2, EIGRP is far more then IGRP with some added extensions. Like IGRP, EIGRP is a distance vector protocol and uses the same composite metrics as IGRP uses. Beyond that, there are few similarities. IGRP was removed as of IOS releases 12.2(13)T


Cisco developed IGRP in the mid-1980 as an answer to the limitations of RIP but still sharing many operational characteristics with RIP: Its still a classful distance vector protocol that periodically broadcast its entire routing table(with the exception of routes suppressed by split horizon) to all its neighbors, convergence based on timers, etc.

The most significant changes brought by IGRP were the hop count metric and the 15-hop network size, which carries over into EIGRP.

IGRP Metrics

IGRP calculates a composite metric from a variety of route variables (bandwidth, delay, load, reliability). 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.

Although the composite metric can use 4 variables, by default IGRP use bandwidth and delay only.


All variables used by IGRP in building the composite metric are visible via “show interface”.

Bandwidth value is the inverse of the bandwidth scaled by a factor of which make the value in out example

It is important to mention that serial interfaces on Cisco routers have a default bandwidth value of 1544 no matter what the bandwidth is of the connected link, therefore we can use bandwidth command to adjust it to the correct value.

Delay value is displayed as DLY in units of microseconds and can be changed with the delay command, which specifies the delay in tens of microseconds. In our example delay value calculated by IGRP will be, us


Reliability and load are measured dynamically. For reliability 255 is 100% reliable link and 1 is a minimally reliable link, for example 234/255 or 91.8%. For load, 1 is minimally loaded link and 255 is a 100% loaded link, for example 40/255 or 15.7% load


The composite metric for each IGRP route is calculated as follows:

  • Where,
  • = minimum BW of all the outgoing interfaces along the route to the destination
  • = total DLY of the route
  • The values K1 through K5 are configurable and their default values are k1=k3=1 and k2=k4=k5=0. When k5 is set to zero [k5/RELIABILITY+k4] term is not used which reduce to the default metric:

The routing table itself shows only the derived metric but the actual IGRP metric for is calculated as follows.

Minimum bandwidth of the route from Casablanca to is 512K at Quebec. The total delay of the route is 1000+20000+20000+5000 = 46000 microseconds


The actual IGRP values for delay and bandwidth can be seen in the “show ip route <route>

It is important to note that all metrics are calculated from an outgoing interface perspective along the route. For example, the metric for the route from Yalta to subnet is different from the metric for the route from Casablanca to subnet

IGRP Process Domains

IGRP also uses the concept of process domains, allowing to isolate communications within one domain from communicating with another domain. Traffic between domains can be regulated by redistribution and filtering, allowing a more granular control over routing updates inside the routing domain.


Within AS10, there are two IGRP domains: IGRP 20 and IGRP 30. Even though 20 and 30 are defined in configuration as autonomous system numbers, in this context, the numbers serve to distinguish two routing processes within the same routing domain.

Redistribution between IGRP domains is done automatically

With concept of different IGRP domains, different route types are introduced. Within its update, IGRP classifies route entries into one of three categories: interior routes, system routes and exterior routes


Some other significant advantages introduced by IGRP over RIP are:

*Unequal-cost load sharing

*Update period 90sec three time longer then RIP’s reducing the amount of update transmitted(however, extend the convergence time) [invalid timer is set to 270/flush timer set for 630]

The biggest disadvantage of both IGRP and EIGRP is that they are proprietary to Cisco and therefore limited to Cisco products.



  • The original motivation for developing EIGRP was simply to make IGRP classless. The result was a protocol that, while retaining some concepts introduced with IGRP such as composite metric, protocol domains and unequal-cost load balancing, is distinctly different from IGRP.
  • EIGRP is occasionally described as an advanced distance vector protocol
  • Distance Vector protocols = shares everything it knows, but only with directly connected neighbors
  • Link-States protocols = announce information only about their directly connected links, but they share the information with all routers in their routing domain(area)
  • All the distance vector protocols run some variant of Bellman-Ford algorithm. These are prone to routing loops. As a result, they must implement a loop-avoidance measures such as split horizon, route poisoning and hold-down timers, which might impact severely convergence time in a large scale network.

In contrast to Bellman-Ford algorithms used by most other distance vector protocols, EIGRP uses DUAL algorithm which ensure a fast convergence while remaining a loop-free.

EIGRP packets can be authenticated using MD5

Finally, a major feature of EIGRP is that it can route not only IP but also IPX or AppleTalk.


EIGRP Packet Formats

The IP header of an EIGRP packet specifies protocol number 88. Following the IP header is an EIGRP header followed by various Type/Length/Value(TLV) triplets


General TLV Fields

This TLVs carry EIGRP management information and are not specific to any routed protocol.

IP Specific TLVs

The internal and external routes TLVs include metric information for the route. The metrics used by EIGRP are the same metrics used by IGRP, although scaled by 256


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.

EIGRP has four fundamental components:

1. Protocol-Dependent Module

2. Reliable Transport Protocol(RTP)

3. Neighbor Discovery/Recovery

4. Diffusing Update Algorithm(DUAL)

= 6177536


Reliable Transport Protocol(RTP)

EIGRP have its own transport protocol, RTP(Reliable Transport Protocol) which manage a reliable delivery and reception of EIGRP packets.

Guaranteed delivery is accomplished by using a reliable multicast, Each neighbor receiving a reliable multicast packet unicast an acknowledgement.

Ordered delivery is ensured by including two sequence numbers in the packet(sender’s sequence number and last seq. number received from the neighbor)

There are multiple packet types, all of which are identified by protocol number 88 in the IP header:

a). Hellos

b). Acknowledgements(ACKs)

c). Updates

d). Queries and Replies

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 un-responding neighbor. If an ACK is not received after 16 of these retransmissions, the neighbor will be declared dead.


Neighbor Discovery/Recovery

In the Hello packet received from a neighbor a hold time value will be included, which will tell the router he 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. The default can be changed on a per interface basis.


The reason behind this behavior is an ACL on R2 who drops EIGRP inbound packets

R2 is sending hello messages but never receives any from R1 which results in R1 ONLY, forming a “ non-functional neighbor relation”


As soon as the existing ACL is removed, the neighbor relation is formed and routers exchanged routing updates.


Diffusing Update Algorithm(DUAL)

A typical distance vector when computing the best path to a destination saves the best distance(total metric or distance as hop count) and the vector(the next hop) discarding any other available path.

 With EIGRP, upon startup, a router uses Hellos to discover neighbors and to identify itself to neighbors. Once a neighbor is discovered, EIGRP will attempt to form an adjacency(a logical association between two neighbors over which route information is exchanged) with that neighbor(K values must match in order for an adjacency to form)

As opposed to a typical distance vector, EIGRP builds a topology table based on its neighbor’s advertisements(rather than discarding the data) and converges by either looking for a likely loop-free route in the topology table or if it knows of no other route, by querying its neighbors.


Feasible Distance(FD) is the best metric along a path to a destination network, including the metric to the neighbor advertising that path

Advertised Distance(AD) is the total metric along a path to a destination network as advertised by an upstream neighbor

Feasible Successor(FS) is a path whose reported distance is less than the FD(current best path), Feasibility Condition.

via four:

AD: (10^7/10000+200)*256 = 307200

FD: (10^7/56+2200)*256 = 46277376

via three:

AD: (10^7/10000+200)*256 = 307200

FD: (10^7/128+1200)*256 = 20307200

FD: 20307200, Successor router: three

FS: router four???


From router one perspective:

via four [FD/AD]: 20307200/307200 via two [FD/AD]: 46789376/46277376

FD:(10^7/128+1200)*256 = 20307200 FD:(10^7/56+4200)*256 = 46789376

AD:(10^7/10000 +200)*256 = 307200 AD:(10^7/56+2200)*256 = 46277376

Successor, router four, No Feasible Successor

If the link to router four goes down, One will have no feasible successor towards Network a, therefore it will start to query its neighbors(router two) for a path to Network a.

Router two has installed the path via router three(FD:46277376) therefore will reply to query received from router One, resulting in a new path towards Network a from router one perspective, via router two.



Prefix-lists are used to match on prefix and prefix-length pairs. Normal prefix-list syntax is as follows:

Where, “w.x.y.z“ is your exact prefix and “len” is your exact prefix-length

ip prefix-list LIST permit would be an exact match for the prefix with a subnet mask of

When you add the keywords “ge” or “le” to the prefix-list, the “len” value change its meaning. When using GE and LE, the “len” value specifies how many bits of the prefix you are checking, starting the most significant bit.

check the first 24 bits of the prefix The subnet mask be less than equal to 32

This match everything

This match a default route

In many situations a prefix-list can be replaced with an access-list, however there might be scenarios where an ACL does not match the exact prefix


On R2 we cannot filter by using an ACL without filtering also the summary address coming from R1, – will match first 24 bits, however first 22 will match the same bits from our summary address. By using following ACL, access-list 1 deny we drop and


Route Maps

Route maps is a powerful tool for creating customized routing policies. They are similar to ALC, both having criteria for matching the details of certain packets and an action of permitting or denying those packets.

Unlike access-lists, route maps can add to each “match” criteria a “set” criteria that actually changes the packet in a specific manner

Each route map statement has a “permit” or “deny” action and a sequence number. At the end, an implicit deny exist as for ACLs.

A packet or route is passed sequentially through route-map statement . If a match is made, any set statement are executed and the permit or deny action is executed. As with ACLs, processing stops when a match is made and the specific action is executed. The route or packet is not passed to subsequent statements.


Network statement

The network statement control what interfaces are running the EIGRP process. By using a wildcard mask we can be more specific in identifying an interface(s)


EIGRP Auto-summary

EIGRP was built as a classless protocol, however, by default still have a classful behavior to facilitate interaction with IGRP. With auto-summarization enabled by default, networks are summarized as they pass through the major network boundary.


Having auto-summary on, will prevent advertisement of discontiguous networks.

With EIGRP auto-summary disabled the subnets of the discontiguous network can be advertised.


EIGRP Topology table

Once the adjacency is established, every EIGRP router is building it’s own topology table.


EIGRP equal cost load balancing

By default EIGRP load balance traffic over 4 equal paths(with the same metric)

By altering values of delay or bandwidth we can get equal metrics towards a destination resulting in load balancing traffic over multiple paths


By default, load balancing is done on a per-destination which will not imply an equal distribution of traffic over the used links.

We can see by sending 2 packets of ICMP traffic, both have as an outbound interface s0/0(


By disabling IP CEF we are getting a packet switching forwarding type of traffic, resulting in per packet load balancing and a more visible traffic share between links.


EIGRP unequal load balancing

 By default EIGRP uses bandwidth and delay to calculate its composite metric. Load and reliability can also be used, or the ratio at which bandwidth and delay are used can be changed by modifying the metric weights.

The default weighting of K1 =1 and K3 = 1 means that only bandwidth and delay are used.


show ipeigrp topology show the individual vector metrics that are used in the composite calculation

Trying to engineer traffic in a more complex network can get in very complicated calculations using both values, therefore we can select to have only the value(s) that we consider useful or required in our specific scenario.

A very important thing to remember is that K values must match on both sides, otherwise an adjacency will not be formed.


We can see now, the value of the composite metric has changed and is determined by the delay value only.

By default EIGRP load balance traffic over up to 4 equal paths, however, the option to load balance traffic over unequal paths is available. In order to so, we need to define the variance value(by default is 1).

The variance is a multiplier and traffic will be placed on any link that has a metric less than the best path multiplied by variance. In order for EIGRP to consider a path for unequal load balance, it must pass the Feasibility Condition.


Delay values were reset back to default values and we’ll try to achieve an unequal load balance in a 5:1 traffic share towards from R1.

By default we can see that we have no FS for

We need to ensure that R1 will have a FS in order to share traffic over unequal paths. To do that we need to engineer existing delay values.


For simplicity we’ll use low values. Now, in order for R3 to become a FS it need to advertise a better metric than R1 already have(10+20).

With R3’s s0/2 delay changed to 10usec


In order to have a 5:1 traffic share we’ll need to have R1:R2 composite metric 5 times better than R1:R3, which lead to following relation 5*30 = 20 + x


Based on existing metric values we’ll need to use a variance value of 3840/768 = 5

In order to have a per packet load balancing, we disable IP CEF


EIGRP Summarization

EIGRP support summarization at the interface level anywhere through the topology. When a summary is configured in EIGRP all subnets that make up the summary are suppressed from being advertised out the link.

Design-wise this can be used to both reduce the size of the routing table and to limit the scope of EIGRP query messages


EIGRP Summarization with Default Routing

Summarization can also be used to originate a default route in EIGRP. The disadvantage of this configuration however is that all subnets previously advertised out an interface will be suppressed, since all IPv4 networks are a subnet of the aggregate


EIGRP Summarization with a leak-map

 The leak-map feature of the summary-address allows the advertisement of specific subnets encompassed by interface level summary. Routes matched in the leak-map route-map will be advertised in addition to the summary


Route-map used into the leak-map will allow un-suppressing matched prefixes by a summary address witch match everything(default route)


EIGRP Authentication

MD5, is the only authentication supported in EIGRP.

As soon as we have authentication configured on the other side too, adjacency is reformed


EIGRP permits using a rotation for keys based on a timestamp.

Anytime time based authentication is configured, we must ensure that all devices agree on the same time(NTP, manually set clock)


EIGRP over NBMA networks

There are 2 major problems which need to be discussed with EIGRP over NBMA

Non-broadcast behavior pose a problem for EIGRP because as we know multicasts are used to discover/maintain neighbors.

Frame-Relayfor example use a pseudo broadcast by adding the key broadcast for a manual mapping. In this way broadcasts/multicasts will be replicated over every DLCI


Another option we have is to manually configure a neighbor by using a neighbor <IP> statement under EIGRP process

Once broadcast key-word is removed, all Hello packets cannot be sent anymore

To fix this issue, we’ll manually add a neighbor on both sides R4 and R3


The second problem for EIGRP over NBMA is related to split-horizon which states that an update received on an interface, cannot be forwarded back on the same interface

 For a clarity P2P link between R1 and R3 will be admin down.


As soon as split-horizon is disabled on s0/2(R4) all prefixes will be installed on R3 routing table

Altough disabling split-horizon on R5 does not cause a routing loop, it does add an additional route replication into the topology. Even though there are multiple paths to the same destination a loop cannot occur based on the EIGRP feasibility condition.


EIGRP Convergence Timers

Unlike OSPF, EIGRP hello intervals don’t need to match in order to form adjacency. Instead, the neighbor sending the hello packet tells the adjacent router what its hold time is for that particular hello.

EIGRP sends hello packets every 5 seconds on high bandwidth links and every 60 seconds on low bandwidth multipoint links

Note that if you change the hello interval, the hold time is not automatically adjusted to account for this change


EIGRP Stub Routing

The EIGRP Stub feature is used to limit the scope of EIGRP query messages and to limit what routes a neighbor advertise(Summarization it’s another way to limit the query range)

 Based on the following example we can see that queries generated by R1 will travel through the entire network


R4 will receive the query generated by R1 even though R4 will never have any alternate path because it’s a stub

Configuring R4 as a stub router will limit the query scope to R3, which will not send any queries to R4


Now that R4 it’s a stub, R3 will not forward anymore queries towards R4. However, an update about losing connection towards will be sent by R3 to R4

We’ll try to extend the stub branch to see the effects of using the stub feature.


Having R4 as a stub router will imply by default that it would advertise ONLY connected and summary routes.

A fix will be required if we need R5 to have reachability to the rest of the network


EIGRP Stub Routing with Leak Map

The leak-map feature of EIGRP stub, like the leak-map for EIGRP summarization, allows the advertisement of routes that would normally be suppressed.


EIGRP filtering with Passive Interface

The passive-interface command in EIGRP stops the sending of updates out an interface. The secondary effect of using a passive-interface is that EIGRP will stop forming an adjacency on the interface and hence the learning of any updates on the link

There are two ways of using the passive-interface feature:

for every required interface passive-interface <interface>

for all interfaces by using passive-interface default under the EIGRP process and then for required interfaces disable the passive interface feature with no passive-interface <interface>


EIGRP Filtering with Standard Access-Lists

We’ll try to filter on R1.

Before filter

After filter


EIGRP Filtering with Extended Access-Lists

Extended ACL when called as a distribute-list in IGP should be interpreted in the following way: the “source” field in the ACL matches the update source of the route and the “destination” field represents the network address.

This implementation allows us to control which networks we are receiving , but more importantly who we are receiving them from.

We’ll try to filter coming from R3

Before filtering

After filtering


EIGRP Filtering with Offset Lists

The offset-list feature in EIGRP is used to modify the metric on a per-route basis or a per-interface basis. We’ll try to force the path from R1 to via R2

Before filter

After filter


EIGRP Filtering with Prefix-Lists

By using a prefix-list EIGRP allow not only to filter a prefix but also the origin of that prefix. We’ll try to filter on R1

Before filter

After filter


EIGRP Filtering with Administrative Distance

Like other IGP protocols, administrative distance can be set on a per-prefix basis in EIGRP. Administrative distance of 255 represent “infinite” and the route in question cannot be installed in the routing table or EIGRP topology.

Before filter

After filter


Administrative distance can be set on a per-prefix per-neighbor basis in EIGRP. We’ll try to filter on R3 coming from

Before filter

After filter


EIGRP Filtering with Route-Maps

We’ll try to filter on R1 based on tag value

Before filter

After filter


EIGRP permit filtering based on metric values. The route-map can match an absolute value, such as with the match metric 10 , or on a range of metrics. The metrics in the range of 100,000 – 300,000 are filtered based on matching the value 200,000 +- 100,000

We’ll filter on R5 metrics in the following range 400,000 – 440,000

Before filtering

After filtering



1. CCIE Professional Development Routing TCP/IP, Volume I, Second Edition

by Jeff Doyle -  CCIE No. 1919, Jennifer Carroll -  CCIE No. 1402

2. CCIE Routing & Switching Lab Workbook for CCIEv4.0, volume I


3. Troubleshooting IP Routing Protocols,

by Zaheer Aziz(CCIE#4127), Johnson Liu(CCIE#2637)

4. CCNP ROUTE 642-902, Official Certification Guide

by Wendell Odom, CCIE No. 1624

5. Enhanced Interior Gateway Routing Protocol