Configuration
EIGRP Fundamentals
Let’s take a few minutes to review EIGRP fundamentals and add to those mentioned in the Basic EIGRP section.
EIGRP is a Cisco-proprietary protocol that improves greatly on the original version of this protocol,
the Interior Gateway Routing Protocol (IGRP). (The “E” in EIGRP stands for enhanced.)
The benefits of using EIGRP include:
Support for Appletalk, IP, and IPX (Novell Netware) via protocol-dependent modules (PDMs)
Support for variable-length subnet masking (VLSM)
Dynamic neighbor discovery
via packets multicast to 224.0.0.10
Fast convergence after network topology changes -backup routes are actually calculated and placed into a table in advance of their actually being needed. (Note:
This table is NOT the IP routing table.)
Where RIP sends routing updates every 30 seconds, even if nothing has changed,
EIGRP will send routing updates only when a network topology change actually occurs.
EIGRP updates do not contain the entire routing table, but reflect only the routes that have been changed.
The scope of these updates is limited to the routers that actually need them - they’re not flooded.
Those last two points might not sound like much, but everything we do on a Cisco router has a cost in CPU and time. If your routing table has 105 routes and only 1 has changed, why take the time to create an update for every single route when an update reflecting only the change will serve our purpose?
EIGRP’s routing algorithm is the Diffusing Update Algorithm (DUAL). DUAL not only calculates routes that ensure a loop-free network, but also calculates backup routes before they’re needed.
These backup routes, the feasible successors, are kept in the EIGRP topology table. The primary routes, the successors, are kept in both the EIGRP topology and route tables.
EIGRP’s third table is the neighbor table, which contains just what you would think it does - information about EIGRP neighbors.
EIGRP is a classless routing protocol, which means it supports Variable Length Subnet Masking (VLSM). EIGRP routing update packets contain a prefix length for each individual network, making VLSM support possible.
EIGRP uses metric weights to determine how important certain values are in route calculation. By default, bandwidth and delay are the only metric values used in route calculation. The other metric weights, or “k-weights”, are load, reliability, and MTU.
You can change the bandwidth and delay values to alter EIGRP path selection. If you’re changing any EIGRP values to fine-tune your routing table, I’d go with bandwidth as it’s simply easier to get the desired results.
The bandwidth command is entered in kbps and should be set to the minimum bandwidth of the path.
The delay command is configured in tens of microseconds. As you’d guess, the bandwidth command is easier to use for fine-tuning routes.
R1(config)#int s0
R1(config-if)#bandwidth ?
<1-10000000> Bandwidth in kilobits
R1(config-if)#bandwidth 64 R1(config-if)#delay ?
<1-16777215> Throughput delay (tens of microseconds)
Since DUAL actually calculates
backup routes before they’re even needed, EIGRP responds to topology changes faster than RIP (which isn’t saying much) and OSPF (which is saying a lot). With EIGRP, routing loops have literally no time to form.
EIGRP will perform equal-cost load-sharing over four paths by default, with a maximum of 16 paths. That value is configurable with the maximum-paths command.
R1(config)#router eigrp 100
R1(config-router)#maximum-paths ?
<1-16> Number of paths
We can also perform unequal-cost load balancing with EIGRP, and we’ll practice that skill later in this section.
Almost all EIGRP packets are multicast to 224.0.0.10, and use IP protocol number 88. Let’s take a look at the different EIGRP packet types… and see if we can spot that exception to the multicast rule.
EIGRP Packet Types And RTP EIGRP uses the Reliable Transport Protocol (RTP) to handle the guaranteed and reliable delivery of
EIGRP packets to neighbors.
“Guaranteed and reliable” sounds a lot like TCP, but the two are quite different in how they operate. Not all EIGRP packets are going to be sent reliably.
Hello packets are used for neighbor discovery and to keep existing neighbor
relationships alive; these are multicast to 224.0.0.10.
Acknowledgement packets themselves are simply hello packets that contain no data.
Neither Acks nor Hellos use RTP, and are therefore
considered unreliable.
Update packets are sent to new neighbors to allow the neighbor to build an accurate routing and topology table, and are also sent when a change in the network occurs. Update packets are generally multicast packets, but there’s one
important exception that you’ll read about later in this section.
Query packets are sent when a router loses a successor route and has no feasible successor.
Reply packets are sent in response to query packets, and a reply packet indicates that a new route to the destination has been found. Update, query, and reply packets all use RTP and are considered reliable.
To see how many of these packets have passed through a router, run show ip eigrp traffic.
R1#show ip eigrp traffic
IP-EIGRP Traffic Statistics for process 100 Hellos sent/received: 2/2
Updates sent/received: 13/4 Queries sent/received: 0/0 Replies sent/received: 0/0 Acks sent/received: 0/2
Input queue high water mark 1, 0 drops SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0
To review: Hello and ACK packets are unreliable. Reply, Query, and Update packets are reliable.
That’s a handy troubleshooting command, too. If the Query, Reply, and Update values remain the same over a period of time, your network is stable.
If they’re constantly incrementing, there’s a problem. The Query and Reply values will increment only if a successor route is lost. If you see those incrementing regularly, you have yourself a flapping link (believe me, I’ve been there). If the SIA values are incrementing along with them, that’s not good - more on that later in this part of the course.
How EIGRP Routers Become Neighbors
EIGRP routers form neighbor
relationships, and after the initial exchange of routing updates between neighbors, EIGRP routers will then only send routing updates when there is a change in the network topology. These neighbor relationships, or adjacencies, begin when a router first has EIGRP enabled on some or all of its interfaces with the router eigrp command.
find potential neighbors.
A downstream router, R2, receives this Hello. If certain values are agreed upon between the two, R2 will respond with an EIGRP Update packet, which contains all the EIGRP-derived routes that R2 knows.
Did you notice that the EIGRP Update packet going back to R1 was a unicast? Generally, EIGRP Update packets are multicast to 224.0.0.10, just as EIGRP Hello packets are.
There’s almost always an exception in networking, and that’s true here as well. Update packets are unicast in this particular situation, but
otherwise they’re multicast.
R1 will send an EIGRP Acknowledgement packet, or ack, to let R2 know the routes in the Update packet were received. R1 will also send an Update packet of its own, unicast to R2, containing all EIGRP routes R1 has. R2 will respond with an ack of its own.
Other EIGRP Adjacency Issues (And Non-Issues)
Unlike OSPF, EIGRP does not require neighbors to agree on hello and dead times. The EIGRP hold time has the same function as OSPF dead time - they’re both the duration of time in which a hello must be received in order to retain the neighbor relationship. The default EIGRP hold time is three times the hello time.
In the following example, an adjacency has been formed between R2 and R3 using the default values
for hello and hold times as well as the metric weights. The router eigrp command indicates that both routers are in EIGRP Autonomous System (AS) 100. The AS is a logical group of EIGRP-speaking routers, and this value must match between potential neighbors.
Routers must agree on the EIGRP AS number in order to become neighbors, and the interfaces through which the adjacency is to form must be on the same IP subnet.
In the following example, both routers will be placed into EIGRP 100 via the following interfaces:
R2: Ethernet0, 172.12.23.2 /24 R3: Ethernet0, 172.12.23.3 /24
R2(config)#router eigrp 100
R2(config-router)#no auto-summary
R2(config-router)#network 172.12.23.0 0.0.0.255
R3(config)#router eigrp 100
R3(config-router)#no auto-summary
R3(config-router)#network 172.12.23.0 0.0.0.255
show ip eigrp neighbor verifies that R3 is a neighbor of R2.
Let’s change the hello timers on R2’s Ethernet 0 interface and see what happens to the adjacency. I’ve disabled EIGRP event logging for the following example.
Note the uptime of 12 seconds. That indicates that the EIGRP adjacency did drop, but it came right back up.
The mismatched Hello timers didn’t prevent the adjacency from forming again, but what about a change in
the metric weights?
R2(config)#router eigrp 100 R2(config-router)#metric weights ?
<0-8> Type Of Service (Only TOS 0 supported)
R2(config-router)#metric weights 0 1 1 1 1 1
R2#show ip eigrp neighbor
IP-EIGRP neighbors for process 100 R2#
show ip eigrp neighbor shows us nothing because there’s no neighbor to show! We can wait a long, long time for that adjacency to come back, but it’s not going to. Potential EIGRP neighbors must agree on the
AS number and all metric weight settings in order to become neighbors.
A great command to begin troubleshooting adjacencies with is debug eigrp packets, and if there’s a metric weights mismatch, you’ll see the following:
R2#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, 01:10:00: K-value mismatch
The K-value mismatch message indicates a problem with the metric weight setting.
In short, EIGRP neighbors must….
… reside in the same EIGRP AS
… be on the same subnet
… have matching metric weights
A quick note on that ip hello eigrp command - unlike OSPF, changing the EIGRP hello time does not
dynamically change the hold time (dead time).
EIGRP Hello Packets
Hello packets find potential neighbors and also keep neighbor relationships alive. On a high-speed link, EIGRP Hello packets are sent every 5 seconds; on slower links, Hellos are sent every 60 seconds.
High-speed links include broadcast technologies such as Ethernet, FDDI, and our old friend Token Ring; high bandwidth (over T1 speed) multipoint circuits, including
ISDN Primary Rate Interface and Frame Relay; both Frame Relay and ATM point-to-point subinterfaces;
and finally, point-to-point serial links, such as PPP and HDLC circuits.
After that list, you might think there aren’t any interface types left, but there are!
Low-speed links include multipoint circuits running at less than T1 speed, such as ATM switched virtual circuits and multipoint interfaces, Frame Relay multipoint interfaces, and ISDN Basic Rate
Interface.
An EIGRP neighbor relationship is declared dead when three hello packets are missed, meaning the EIGRP dead time on an ethernet segment is 15 seconds and 180 seconds on an NBMA interface such as a Serial interface. If you change the hello transmission time, Cisco recommends you change the hold time as well to keep it to three times the hello value.
To verify EIGRP neighbor relationships, run show ip eigrp neighbors.
From left to right, let’s examine the meaning of these categories:
IP-EIGRP neighbors for process 100 - The AS these neighbors are contained in.
H - The order in which the neighbors were discovered.
Address - The IP address of the neighbor.
Interface - The interface upon which the router is receiving hellos.
Hold - Short for holdtime, the number of seconds the router will wait until it declares this particular adjacency dead.
Uptime - The amount of time since this neighbor was first heard from.
SRTT - Smooth Round-Trip Time.
This is the number of milliseconds it takes for an EIGRP packet to be sent to that neighbor and the amount of time it takes to get an ACK from that neighbor.
RTO - Retransmission TimeOut.
The amount of time the software
will wait until it retransmits a packet to a neighbor.
Q Cnt - Queue Count. The number of EIGRP packets waiting to be sent.
Seq Num - Sequence Number. This is the sequence number of the last update, reply, or query packet that was received from this particular neighbor.
To debug EIGRP adjacencies, you’ve got two options. You can run debug eigrp neighbors, or debug ip eigrp neighbor <AS> <IP
ADDRESS>. Personally, I use
6d00h: EIGRP: Neighbor(172.12.123.3) not yet found
6d00h: EIGRP: Neighbor(172.12.123.2) not yet found
6d00h: EIGRP: Neighbor(172.12.123.3) not yet found
6d00h: EIGRP: Neighbor(172.12.123.2) not yet found
6d00h: EIGRP: Neighbor(172.12.123.3) not yet found
6d00h: EIGRP: Neighbor(172.12.123.2) not yet
found
6d00h: EIGRP: New peer 172.12.123.2 6d00h: EIGRP: New peer 172.12.123.3
EIGRP Adjacencies And Secondary Addresses
Technically, EIGRP will not form adjacencies using secondary addresses.
Even though it looks like it will.
Let’s take a look at R2 and R3, which will be using secondary addresses to form an EIGRP adjacency over an ethernet segment.
R2(config)#interface ethernet0
R2(config-if)#ip address 172.12.23.2 255.255.255.0
R2(config-if)#ip address 23.23.23.2 255.255.255.0 secondary
R2(config)#router eigrp 100
R2(config-router)#no auto-summary
R2(config-router)#network 23.23.23.0 0.0.0.255
R3(config)#interface ethernet0
R3(config-if)#ip address 172.12.23.3 255.255.255.0
R3(config-if)#ip address 23.23.23.3 255.255.255.0 secondary
R3(config)#router eigrp 100
R3(config-router)#no auto-summary
R3(config-router)#network 23.23.23.0 0.0.0.255
Here’s the partial output of show ip eigrp neighbor on R3:
R3#show ip eigrp neighbor
IP-EIGRP neighbors for process 100 H Address Interface 0 172.12.23.2 Et0
The adjacency has formed!
However, the secondary addresses were not used to form the adjacency. Note the address is actually the primary IP address on the interface, even though we used the secondary network number in the EIGRP network command.
How EIGRP Routers Determine Successors And Feasible Successors
Once the EIGRP neighbor relationships form, DUAL will begin sending a series of queries and responses, and these responses are used to build the EIGRP topology table.
These queries and responses are sent by the Reliable Transport Protocol (RTP). As mentioned earlier, show ip eigrp traffic will display the number of queries and replies that have been sent and
received.
R1#show ip eigrp traffic
IP-EIGRP Traffic Statistics for process 100 Hellos sent/received: 110457/115367 Updates sent/received: 43/17 Queries sent/received: 4/0 Replies sent/received: 0/4 Acks sent/received: 14/21
Input queue high water mark 2, 0 drops SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0
Let’s take a look at a typical EIGRP topology table.
R1#show ip eigrp topology
IP-EIGRP Topology Table for
AS(100)/ID(11.1.1.1)
Codes: P Passive, A Active, U Update, Q -Query, R - Reply,
r - reply Status, s - sia Status
P 1.1.1.1/32, 1 successors, FD is 128256 via Connected, Loopback0 P 2.0.0.0/8, 1 successors, FD is 2297856
via 172.12.123.2 (2297856/128256), Serial0
via 172.12.123.3 (2323456/409600), Serial0
P 3.0.0.0/8, 1 successors, FD is 2297856
via 172.12.123.3
P 172.12.123.0/24, 1 successors, FD is 2169856 via Connected, Serial0
EIGRP will keep up to six valid routes for any given destination.
Those six routes don’t have to be made up of one successor and five feasible successors, either - when equal-cost load sharing is in effect as it is for the 172.23.0.0 /16 route in the above topology table, there will be multiple successor routes.
“SIA” -- Stuck In Active
Regarding those codes, notice that all the routes in this table have a
“P” next to them, indicating that these routes are passive. Another code shown is “A”, for Active.
While an “active route” sounds like a good thing, we want to avoid them in EIGRP.
If a route shows as Active in the EIGRP topology table, that means the successor for that route has been lost and that no feasible successor was immediately available in the topology table.
When a route is Passive, that means it’s not being recalculated and it’s a usable route.