Configuring EIGRP. Andrei Bot. April 5 th , 2012. Introduction to EIGRP Concepts EIGRP Basic configuration EIGRP traffic engineering EIGRP filtering. EIGRP concepts. Introduction
April 5th, 2012
EIGRP Basic configuration
EIGRP traffic engineering
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 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 routing table itself shows only the derived metric but the actual IGRP metric for 172.20.40.0/24 is calculated as follows.
Minimum bandwidth of the route from Casablanca to 172.20.40.0/24 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 172.20.4.0/24 is different from the metric for the route from Casablanca to subnet 172.20.40.0/24
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
*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.
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.
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
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
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)
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, 22.214.171.124. 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:
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.
We can see as follows how an update is received by R1 from R2 and acknowledged
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.
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.
AD: (10^7/10000+200)*256 = 307200
FD: (10^7/56+2200)*256 = 46277376
AD: (10^7/10000+200)*256 = 307200
FD: (10^7/128+1200)*256 = 20307200
FD: 20307200, Successor router: three
FS: router four???
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 126.96.36.199/24 would be an exact match for the prefix 188.8.131.52 with a subnet mask of 255.255.255.0.
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 184.108.40.206. 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 10.0.0.0/24 by using an ACL without filtering also the summary address coming from R1, 10.0.0.0/22
10.0.0.0 255.255.255.0 – 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 10.0.0.0 0.0.0.255 we drop 10.0.0.0/24 and 10.0.0.0/22
Using a prefix-list we can deny the /24 prefix while /22 will be permited
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.
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 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 220.127.116.11/16 can be advertised.
Once the adjacency is established, every EIGRP router is building it’s own topology table.
By showing a specific entry in the topology table, we can see the entire vector metric
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(18.104.22.168)
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.
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 22.214.171.124/24 from R1.
By default we can see that we have no FS for 126.96.36.199/24
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 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
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 0.0.0.0/0
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)
MD5, is the only authentication supported in EIGRP.
As soon as we have authentication configured on the other side too, adjacency is reformed
Anytime time based authentication is configured, we must ensure that all devices agree on the same time(NTP, manually set clock)
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.
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
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 188.8.131.52/24 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
The leak-map feature of EIGRP stub, like the leak-map for EIGRP summarization, allows the advertisement of routes that would normally be suppressed.
In this design, R4 is configured to leak dynamically learned route 184.108.40.206/24
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>
We’ll try to filter 220.127.116.11/24 on R1.
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 18.104.22.168/24 coming from R3
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 22.214.171.124/24 via R2
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 126.96.36.199/24 on R1
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.
Administrative distance can be set on a per-prefix per-neighbor basis in EIGRP. We’ll try to filter on R3 188.8.131.52/24 coming from 184.108.40.206
We’ll try to filter on R1 220.127.116.11/32 based on tag value
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
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