Category Archives: EIGRP

Enhanced Interior Gateway Routing Protocol

EIGRP Metric Calculator

bw = 200000
delay = 2900
K1 = 1
K3 = 1
met = 256 * (int(K1 * 10**7 / bw) + K3 * delay / 10)
print met
bw = raw_input(“Bandwidth: “)
dly = raw_input(“Delay: “)
met = 256 * (int(K1 * 10**7 / bw) + K3 * delay / 10)

Use case of EIGRP

First we need to understand some of eigrp features.

Basic Manipulation
Maximum Path – router configuration command, up to 32 equal-cost entries can be in the routing table for the same destination. The default is four.
NOTE: Setting the maximum-path to 1 disables load balancing.
Split-horizon route advertisement is a method of preventing routing loops in distance-vector routing protocols by prohibiting a router from advertising a route back onto the interface from which it was learned.
R5#sh ip protocols
*** IP Routing is NSF aware ***

Routing Protocol is “eigrp 10”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
Redistributing: eigrp 10
EIGRP-IPv4 Protocol for AS(10)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0

NSF-aware route hold timer is 240
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1

Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
Routing Information Sources:
Gateway Distance Last Update 90 00:00:11 90 00:00:11
Distance: internal 90 external 170

For EIGRP network 2 routers play a key rule in determining the best path and the backup path. EIGRP is the only routing protocol that has a backup path to each destination.

EIGRP only advertise what’s in its local table.


1. Query chain become longer and then the neighbor adjacency dead timer could cause lots of problem with SIA(Never Converge).
2. Setting up your maximum-paths ex 8 and you build 32 alternate path everywhere. and you’ll advertising only to all only 8 paths. (set the path to all to stable EIGRP).

Note: theres no whitepaper that eigrp can be use indata center fabric. (maybe because ospf more preferred because they can do traffic engineering.

Use Cases of EIGRP as IGP.
1. Hub and Spoke (Data center fabric “leaf/spine”(havent seen)).
2. Campus Network.
3. Split horizon design features

In IPSEC SA – You don’t want spoke to spoke traffic split horizon help to put in blackhole.

What should be considered when scaling eigrp
Query Range/Scope – Important (Design Problem)
Stub / Filter / Summary and Summary Boundaries.
IP Address

Note: Don’t change the SIA timer up.(how long your’e willing to allow your network not to converge. it already set to maximum)

Bandwidth – Query?

Stub Router
1. Can’t be use as transit, only advertise connected and summary routes.
2. You can never query a stub router.

– Spoke01 will never know that spoke 01 is down.
– Spoke will not query the hub because they don’t know the changes.
– But hub query all the spoke because hub is aware of the change and none of the spoke configured as stub.
– Hub will not query the spoke since it’s configured as stub, But spoke will query the HUB if there a change on routing table.

EIGRP Neighbor Issue

6 Common issue of EIGRP Neighbor.

1. No multicast transport.
Solution: Set/use unicast.

2. Mismatched AS number.
Solution: Redistribution

3. Uni-directional link (one-way-neighborship).
Solution: verify #show ip eigrp neighbor

Smooth round-trip time (SRTT)—The number of milliseconds it takes for an EIGRP packet to be sent to this neighbor and for the local router to receive an acknowledgment of that packet

Retransmission timeout (RTO), in milliseconds—The amount of time that the software waits before retransmitting a packet from the retransmission queue to a neighbor

Q count—The number of EIGRP packets (Update, Query, and Reply) that the software is waiting to send

The Q count is not decrementing, which indicates that the router is trying to send EIGRP packets but no acknowledgement is being received. RTR B will retry 16 times to resend the packet; eventually, RTR B will reset the neighbor relationship with the log indicating RETRY LIMIT EXCEEDED, and the process starts again. Also, keep in mind that the 16 times retransmission of the same packet is done using unicast, not multicast. Therefore, the RETRY LIMIT EXCEEDED message indicates a problem with transmitting unicast packets over the link, and this is most likely a Layer 1 or Layer 2 problem.

The solution to this problem is to troubleshoot from a Layer 2 perspective. In this example, a call to the WAN provider is needed to find out why the circuit from RTR B to RTR A is broken. After the link between RTR B to RTR A is fixed, the problem will be resolved. Output from show ip eigrp neighbors in Example 7-2 shows that the neighbor relationship after the WAN link has been fixed.

4. Uncommon Subnet (mismatched IP Address/Subnet)
LOG MESSAGE: IP-EIGRP: Neighbor ip address not on common subnet for

5. K Values – If there’s a minipulation of K values on devices it can afftect the neighbor peer.

For EIGRP to establish its neighbors, the K constant value to manipulate the EIGRP metric must be the same. Refer to Chapter 6 for an explanation of the K values. In EIGRP’s metric calculation, the default for the K value is set so that only the bandwidth and the delay of the interface are used to calculate the EIGRP metric. Many times, the network administrator might want other interface factors, such as load and reliability, to determine the EIGRP metric. Therefore, the K values are changed. Because only bandwidth and delay are used in calculations, the remaining K values are set to a value of 0 by default. However, the K values must be the same for all the routers, or EIGRP won’t establish a neighbor relationship. Figure 7-8 shows an example of this case.’

For the network in Figure 7-8, K1 is bandwidth and K3 is delay. The network administrator changed the K values of RTR B to all 1s from K1 to K4, while RTR A retains the default value of K1 and K3 to be 1. In this example, RTR A and RTR B will not form EIGRP neighbor relationship because the K values don’t match. Example 7-5 shows the configuration for RTR B.

Example 7-5 Configuration for RTR B in Figure 7-8
RTR B#router eigrp 1
network xxxx
metric weights 0 1 1 1 1 0
RTR B’s configuration includes the extra metric weights command. The first number is the type of service (ToS) number, which, because it’s not supported, gets a value of 0. The five numbers after the ToS are the K1 through K5 values.

Troubleshooting this problem requires careful scrutiny of the router’s configuration. The solu-tion for this problem is to change all the K values to be the same on all the neighboring routers. In this example, in Router A, changing the K values to match the K value of Router B will solve the problem, as demonstrated in Example 7-6.

Example 7-6 Configuring the K Values on Router A to Match Router B
RTR A#router eigrp 1
network xxxx
metric weights 0 1 1 1 1 0

6. Stuck in active (SIA) – Network prefix goes from passive to active.

Log: %DUAL-3-SIA: Route network mask stuck-in-active state in IP-EIGRP AS. Cleaning up


EIGRP Packet Type

Describing EIGRP Packet Types (HA/U/Q/R/R)
1. Hello
– Used to recover/discover and to maintain EIGRP neighbor adjacencies.

– They do not require acknowledgement.

– EIGRP uses small hello packets to discover other EIGRP-enabled routers on
directly connected links.

– EIGRP Hello packets are sent as IPv4 or IPv6 multicast, and use RTP
unreliable delivery. This mean that the receiver does not reply with an
– The reserved EIGRP multicast address for ipv4 is
– The reserved EIGRP multicast address for IPv6 is FF02::A.

– EIGRP Hello packets are sent as multicast packet every 5 second.

However, on multipoint, nonbroadcast multiple access (NBMA) networks, such as X.25,Frame relay and Asynchronous transfer mode (ATM) interfaces with access links of T1(1.544 Mb/s) or slower. Hello packets are sent as unicast packet every 60 seconds.

EIGRP uses a Hold timer to determine the maximum time the router should wait to receive the next Hello before declaring that neighbor as unreachable.

1.a Acknowledgement
– Acks are always sent using a unicast address and contain a non-zero
acknowledgment number
– Acknowledgement is an EIGRP hello packet without data.
– EIGRP Ack packets are always sent as an unreliable unicast. (Unreliable
delivery makes sense, otherwise, there would be an endless loop of

NOTE: RTP uses reliable delivery for EIGRP update, query and reply packets.

2. Update
– Propagates routing information to EIGRP neighbors. UPdate packets are sent
only when necessary. EIGRP contain only the routing information needed and
are sent only to those routers that require it.
– Sent with reliable delivery.
– Unicast or multicast.
– Trigger updates/Periodic updates, Send only when the state of a destination changes. This can include when a new network becomes available, an existing network becomes unavailable, or a change occurs in the routing metric for an existing network.

3. Query
– Looking information to get to the prefix.
– Sent with reliable delivery. Because queries use reliable delivery, the
receiving router must return an EIGRP acknowledgement. The acknowledgment
inform the sender of the quesry that it has received the query message.
– Unicast or multicast.

4. Replies
– Sent in response to an EIGRP query.
– Always sent in response to queries to indicate to the originator that it
does not need to go into Active state because it has feasible successors.
– Sent with reliable delivery
– Unicast

5. Requests
– Request packets are used to get specific information from one or more
– Request packets are used in route server applications.
– They can be multicast or unicast.
– Requests are transmitted unreliably.

Note: Update, Query and Reply require Ack’s.Update, query and reply packets require acknowledgement, whereas hello and ack do not require ack.

Neighborship reset occurs after a 16 retry limit is reached. Slow neighbors will be sent unicast updates instead.


EIGRP Name Mode

EIGRP Name Mode

1. Named Mode
– 64-bit mode
– Address Family (AF) mode
– Multi-Address Family (AF) mode

2. Consolidation of EIGRP configuration stanzas
3. Benefits
– 64-bit metric granularity (We can now differentiate multiple speed interface)
– SHA-256 authentication

How to Enable ‘Named Mode’:
– router eigrp [name]
– address-family [ipv4/ipv6] autonomous-system [#]

Hitless upgrade of existing EIGRP ‘Classic Mode’ Configuration
– eigrp upgrade-cli command

Supported Software Version (
1. IOS version 15.x

## Named mode configuration
(config)#router eigrp cisco
(config-router)#address-family ipv4 unicast autonomous-system 1

## Default passive
(config-router)#address-family ipv4 unicast autonomous-system 1
(config-router-af)#af-interface default

## Removing passive interface
(config-router)#address-family ipv4 unicast autonomous-system 1
config-router-af)#af-interface fastEthernet 1/1
config-router-af-interface)#no passive-interface

## Router ID / Network
(config-router)#address-family ipv4 unicast autonomous-system 1
(config-router-af)#eigrp router-id

R5#sh run | sec router eigrp
router eigrp regreased
address-family ipv4 unicast autonomous-system 1
af-interface default
af-interface FastEthernet1/1
no passive-interface
topology base
eigrp router-id
eigrp stub connected

Now we start to see the benefits! Logical layout in the config where we configure eigrp authentication under eigrp!! A side note that sha256 should also be available if you are running the newer code and md5 isnt considered the most secure anymore.
Now lets configure a legacy style stub on Old_Stub but inject a default from New into this stub area

Again nothing really new but note the name of the virtual router instance (weee/somethingelse) as no significance outside the local router and aren’t required to match.

## Upgrade Classic eigrp to named mode

R3#sh run | sec router eigrp
router eigrp 1

R3(config)#router eigrp 1
R3(config-router)#eigrp upgrade-cli

My final verdict:
There are 2 added few feature that will help interms of adding more secured authentication in neighbor formation and the 64bit metric granularity. But full advantage is the neatness and consolidation of the configuration unlike the classic/legacy mode.


EIGRP Stuck in active (SIA)

Q. What does the EIGRP stuck in active message mean?

A. When EIGRP returns a stuck in active (SIA) message, it means that it has not received a reply to a query. EIGRP sends a query when a route is lost and another feasible route does not exist in the topology table. The SIA is caused by two sequential events:
The route reported by the SIA has gone away.
An EIGRP neighbor (or neighbors) have not replied to the query for that route.
When the SIA occurs, the router clears the neighbor that did not reply to the query. When this happens, determine which neighbor has been cleared. Keep in mind that this router can be many hops away. Refer to What Does the EIGRP DUAL-3-SIA Error Message Mean? for more information.


EIGRP Successor and Feasible Successor

Feasible Distance(FD) – The Feasible Distance, or FD in short, is the historical minimum of the best metric towards that particular destination (with the history starting from scratch when the route neds to enter the Active state and then returns back to Passive state). This means that the FD may be equal to or lower than the current total best metric towards the destination, including the link to the next hop (or successor in EIGRP parlance).

Reported Distance(RD) – Reported Distance, or RD, as advertised by a particular neighbor, is its current total distance to a particular destination. It is simply the neighbor’s own distance to the destination. Our total distance via a particular neighbor is that neighbor’s RD plus the metric of the link between us and that neighbor.

The successor route is the best route to reach a subnet, based on the advertised distance (AD) from the neighbor plus the distance to reach that neighbor. This is the route which is installed in the routing table.

The feasible successor route is a route which has a higher metric than the successor route to reach a subnet but meets the feasibility condition and can be used in the event that the successor route goes down. This route does NOT get installed in the routing table but is kept in the topology table.

Successor – A successor route (think successful!) is the best route to a remote network. A successor route is used by EIGRP to forward traffic to a destination and is stored in the routing table. It is backed up by a feasible successor route that is stored in the topology table-if one is available.

Feasible successor – A destination entry is moved from the topology table to the routing table when there is a feasible successor. A feasible successor is a path whose reported distance is less than the feasible distance, and it is considered a backup route.

EIGRP will keep up to six feasible successors in the topology table. Only the one with the best metric (the successor) is placed in the routing table. The show ip eigrp topology command will display all the EIGRP feasible successor routes known to a router.

The best route is determine by your metric to each network or device.

The feasibility condition states that the AD from a neighbor must be less than the metric of the successor route (the feasible distance [FD]) because routing through a feasible successor when the AD > FD may cause a routing loop.

All other routes (non-successor and non-feasible successor) are called possibilities are kept in the topology table but are only visible when u supply the all-links argument to the show ip eigrp topology command.

By default, an EIGRP router will store only the route with the best (lowest) feasible distance in the routing table (or, multiple routes with equivalent feasible distances). However, under certain conditions, EIGRP will also maintain less-than-optimal routes in its topology table. These feasible successor routes are not used in the forwarding of traffic, but can be injected into the routing table immediately in place of a failed successor route, to avoid the querying process mentioned earlier.


EIGRP VS OSPF Convergence

Different answer on EIGRP and OSPF convergence time:

1. I think you can configure both to converge extremely fast, but if I had all Cisco routers, I would prefer EIGRP because of it’s flexibility regarding the design. OSPF has it’s own rules (area 0, filtering/summarizing only on abrs, etc.)

However, with OSPF ip ospf dead-interval minimal hello-multiplier 4 you can set 4 hellos per second (gives hello interval = 250ms), adjust dead timer to 1 second and you will have a pretty fast convergence. I don’t know whether with EIGRP you can get under 1 second for a neighbor to fall.

2. If EIGRP has a feasible successor route in it’s topology table and the active route in the route table fails then it is almost instantenous in terms of failing over to the new route because EIGRP does not need to query any other routers or do any internal calculations, it simply installs the new route.

3. EIGRP convergence time increases as more routes need to be processed. However, there is a far bigger impact for networks with EIGRP feasible successors than for networks with no feasible successors.

Subsecond timers are not available for EIGRP. Experimentation suggests that setting the EIGRP timer below 2 seconds can lead to instability. The recommended EIGRP minimum timer settings are 2 seconds for hellos and 6 seconds for the dead timer. Subsecond settings are not an option, While OSPF Subsecond hellos are supported DeadInterval-minimum 1 second

Hello multiplier is used to specify how many Hellos to send within 1 second

Additional Article:

EIGRP is now an IETF draft so it’s no longer proprietary. See

If we look at EIGRP with default settings and OSPF with default settings and there are multiple loop free paths to a destination then EIGRP will converge much faster because it keeps what are called feasible successors in it’s topology database. These are basically loop free alternatives to the best path. EIGRP also has summarization at any point in the network. It also has stub feature which is useful when you don’t want to use a router for transit. Commonly deployed in DMVPNS. EIGRP is also less confusing than OSPF because it does not have different network types and EIGRP is easier to deploy in hub and spoke scenarios.

EIGRP uses a flat network without areas, this can both be an advantage and disadvantage.

OSPF is obviously an open standard so it’s the logical choice if you have multiple vendors. It can perform well but it requires that you tweak SPF timers because by default in IOS there is a 5 second wait before running the SPF algorithm. OSPF uses areas which means you can segment the network more logically. OSPF can only summarize between areas. OSPF is link state so it has a better view of the entire network than EIGRP before it runs the SPF algorithm. Network administrators will usually be more comfortable with OSPF because it’s more commonly deployed.

Both protocols have advantages and disadvantages. But the common answer that EIGRP should be discarded because being proprietary is not entirely true any longer.

From a practicle perspective I would say that in the case of EIGRP vs OSPF, OSPF always wins for the following reasons:

Convergence Speed:
Everyone always mentioned that EIGRP is faster than OSPF using default settings. If you deploy either protocol without reading about them and use their default settings, then you clearly don’t know what you are doing in my opinion. Why would you deploy default settings without knowing what they are, and when you do realise what they are you realise that OSPF supports BFD and becomes lightening quick (as does ISIS).

Traffic Engineering:
Because OSPF like ISIS is based on TLV values, it has been extended quite a lot. It has support for extensions like MPLS-TE and GMPLS.

Continual Expansion
As I mentioned above, OSPF and ISIS have been extended quite a lot and extension drafts are being written fairly regularly and will continue to be. EIGRP doesn’t have many of the advanced options these two do.

OSPF scales better than EIGRP with its use of areas however, I don’t think this really matters either (like the convergence time aregument, due to BFD). Not many people are running 10k routes in one area in OSPF. Typically I would use an IGP for fast routing within a given part of a network, but ultimately iBGP carries all the internal routes. Every single router doesn’t need every internal route in its RIB sourced via OSPF if you have hundreds or thousands or routers, some of them are so far away (topologically speaking) it’s worthless knowing about them.

Lastly there is the obviously reason that EIGRP is/was a Cisco proprietary technology. Although this has recently been submitted into a draft for other software vendors to start incorporating, it’s too late (I believe). No currently running network is going to waste huge sums of money switching from some other IGP to EIGRP, and I don’t know why a new network would consider it (if you are going to be mixing Cisco equipment with non-Cisco). Simply because non-Cisco equipment that supports OSPF has been doing so for years. The code is tried and test, many bugs fixed, oodles of information on line etc. It will take years for EIGRP to catch up (if it isn’t too late already!).

Why EIGRP uses Bandwidth and Delay only by Default to calculate the Metric?

What is EIGRP K Value’s?
Enhanced Interior Gateway Routing Protocol uses composite metric calculation formula to select the best available route for destination. This formula uses five metric components. These are Bandwidth, Load, Delay, Reliability and MTU.

Why is better to tweak B & D?
K Parameters/Value like load and reliability can change dynamically, and therefore the metric would also change. As a result the traffic may take a different path.

Also because loading and reliability are dynamic values and they can change over time. You don’t want your EIGRP routers calculating 24/7 and sending updates to each other just because the load or reliability of an interface has changed.

MTU is being exchanged between EIGRP neighbors but not used for the metric calculation.

While Bandwidth and Delay are predefined values, so that the traffic will always go on the path you want it to go. If use Bandwidth and delay static values our EIGRP routers don’t have to do any recalculation unless an interface goes down or a router died.

For example an ISP could benefit from using the dynamic K-values when they face massive load on the network, but a corporate network with primary and secondary connections would become too complicated. So it depends on what you design goal is.Let’s say that the ISP has two possible way to reach a specific subnet. One link in the ISP’s network is getting so much load that the packets start being dropped. If the K-value for load is on, the metric for the path on that link would be worse than the other. The other link could become better to reach the subnet. When the load wasn’t that much on the first link, the routing would take the traffic back to the original path.

The load influences the metric calculation, then the path with the better metric wins and the routing table will be updated. EIGRP will do it automatically.