EIGRP

 Enhanced Interior Gateway Routing Protocol   

EIGRP

EIGRP is a Cisco protocol that runs on Cisco routers and on some Cisco switches.  EIGRP is a Cisco-proprietary Hybrid routing protocol, incorporating features of both Distance-Vector and Link-State routing protocols.  

EIGRP Features and Operations   

(i) EIGRP uses Diffusing Update Algorithm (DUAL) to determine the best path among all “feasible” paths. DUAL also helps ensure a loopfree routing environment.  

(ii) EIGRP will form neighbor relationships with adjacent routers in the same Autonomous System (AS).  

(iii) EIGRP traffic is either sent as unicasts, or as multicasts on address 224.0.0.1 depending on the EIGRP packet type.  

(iv) Reliable Transport Protocol (RTP) is used to ensure delivery of most EIGRP packets.

(v)  EIGRP routers do not send periodic, full-table routing updates. Updates are sent when a change occurs, and include only the change.  

(vi)  EIGRP is a classless protocol, and thus supports VLSMs.

(vii)  EIGRP supports IP, IPX, and Appletalk routing. 

(viii)  EIGRP applies an Administrative Distance of 90 for routes originating within the local  Autonomous System.  

(ix)  EIGRP applies an Administrative Distance of 170 for external routes coming from outside the local Autonomous System

(x)   EIGRP uses Bandwidth and Delay of the Line, by default, to calculate its distance metric. It also supports three other parameters to calculate its metric: Reliability, Load, and MTU.  

(xi) EIGRP has a maximum hop-count of 224, though the default maximum hop-count is set  to 100.  

EIGRP tables  

(i)  Neighbor table – list of all neighboring routers. Neighbors must belong to the same  Autonomous  System

(ii) Topology table – list of all routes in the Autonomous System.

(iii) Routing table – contains the best route for each known network

EIGRP Neighbors

EIGRP forms neighbor relationships, called adjacencies, with other routers in the same AS by exchanging Hello packets. Only after an adjacency is formed can routers share routing information. Hello packets are sent as multicasts to address 224.0.0.10.

By default, on LAN and high-speed WAN interfaces, EIGRP Hellos are sent every 5 seconds. On slower WAN links (T1 speed or slower), EIGRP Hellos  are sent every 60 seconds by default.

The EIGRP Hello timer can be adjusted on a per interface basis:
Router(config-if)# ip hello-interval eigrp 10 7

(This command allows us to change the hello timer to 7 seconds for Autonomous System 10) 

In addition to the Hello timer, EIGRP neighbors are stamped with a Hold timer. The Hold timer indicates how long a router should wait before marking a neighbor inactive, if it stops receiving hello packets from that neighbor.

By default, the Hold timer is three times the Hello timer. Thus, on highspeed links the timer is set to 15 seconds, and on slower WAN links the timer is set to 180 seconds.  

The Hold timer can also be adjusted on a per interface basis: 

Router(config-if)# ip hold-interval eigrp 10 21 

(This command allows us to change the hello timer to 21 seconds for Autonomous System 10) 

Changing the Hello timer does not automatically change the Hold timer. Additionally, Hello and Hold timers do not need to match between routers for an EIGRP neighbor relationship to form.  

A neighbor table is constructed from the EIGRP Hello packets, which includes the following information: 

(i) The IP address of the neighboring router.

(ii) The local interface that received the neighbor’s Hello packet.

(iii) The Hold timer.

(iv) A sequence number indicating the order neighbors were learned.

Adjacencies will not form unless the primary IP addresses on connecting interfaces are on the same subnet. Neighbors cannot be formed on secondary addresses. 

If connecting interfaces are on different subnets, an EIGRP router will log the following error to console when a multicast Hello is received: (Check) 

Always ensure that primary IP addresses belong to the same subnet between EIGRP neighbors. 

To log all neighbor messages and errors to console, use the following commands:
Router(config)# router eigrp 10
Router(config-router)# eigrp log-neighbor-changes
Router(config-router)# eigrp log-neighbor-warnings 

The EIGRP Topology Table 

Once EIGRP neighbors form adjacencies, they will begin to share routing information. Each router’s update contains a list of all routes known by that router, and the respective metrics for those routes. 

All such routes are added to an EIGRP router’s topology table. The route with the lowest metric to each network will become the Feasible Distance (FD). The Feasible Distance for each network will be installed into the routing table.

The Feasible Distance is derived from the Advertised Distance of the router sending the update, and the local router’s metric to the advertising router. 

Router A has three separate paths to the Destination Network, either through Router B, C, or D. If we add up the metrics to form a “distance” (the metrics are greatly simplified in this example), we can determine the following:

• Router B’s Feasible Distance to the Destination Network is 8. 
• Router C’s Feasible Distance to the Destination Network is 23.
• Router D’s Feasible Distance to the Destination Network is 9. 

Router B sends an update to Router A, it will provide an Advertised Distance of 8 to the Destination Network. Router C will provide an AD of 23, and D will provide an AD of 9.  

Router A calculates the total distance to the Destination network by adding the AD of the advertising router, with its own distance to reach that advertising router. For example, Router A’s metric to Router B is 8; thus, the total distance will be 16 to reach the Destination Network through Router B.

Remember, however, that Router A’s Feasible Distance must be the route with the lowest metric. If we add the Advertised Distance with the local metric between each router, we would see that:

• The route through Router B has a distance of 16 to the destination
• The route through Router C has a distance of 27 to the destination
• The route through Router D has a distance of 11 to the destination

Thus, the route through Router D (metric of 11) would become the Feasible Distance for Router A, and is added to the routing table as the best route. This route is identified as the Successor. 

To allow convergence to occur quickly if a link fails, EIGRP includes backup routes in the topology table called Feasible Successors (FS). A route will only become a Successor if its Advertised Distance is less than the current Feasible Distance. This is known as a Feasible Condition (FC).

For example, we determined that Router A’s Feasible Distance to the destination is 11, through Router D. Router C’s Advertised Distance is 23, and thus would not become a Feasible Successor, as it has a higher metric than Router A’s current Feasible Distance. Routes that are not Feasible Successors become route Possibilities. 

Router B’s Advertised Distance is 8, which is less than Router A’s current Feasible Distance. Thus, the route through Router B to the Destination Network would become a Feasible Successor. 

Feasible Successors provide EIGRP with redundancy, without forcing routers to re-converge (thus stopping the flow of traffic) when a topology change occurs. If no Feasible Successor exists and a link fails, a route will enter an Active (converging) state until an alternate route is found. 

EIGRP Packet Types 

EIGRP employs five packet types:

(i) Hello packets - multicast

(ii) Update packets – unicast or multicast

(iii) Query packets – multicast

(iv) Reply packets – unicast

(v)  Acknowledgement packets - unicast 

Hello packets are used to form neighbor relationships, and were explained  in detail previously. Hello packets are always multicast to address 224.0.0.10.

Update packets are sent between neighbors to build the topology and  routing tables. Updates sent to new neighbors are sent as unicasts. However, if a route’s metric is changed, the update is sent out as a multicast to address
224.0.0.10.

Query packets are sent by a router when a Successor route fails, and there are no Feasible Successors in the topology table. The router places the route  in an Active state, and queries its neighbors for an alternative route. Query packets are sent as a multicast to address 224.0.0.10.

Reply packets are sent in response to Query packets, assuming the responding router has an alternative route (feasible successor). Reply packets are sent as a unicast to the querying router.

Recall that EIGRP utilizes the Reliable Transport Protocol (RTP) to ensure reliable delivery of most EIGRP packets. Delivery is guaranteed by having packets acknowledged using Acknowledgment packets! 

Acknowledgment packets (also known as ACK’s) are simply Hello packets with no data, other than an acknowledgment number. ACK’s are always sent as unicasts. The following packet types employ RTP to ensure reliable delivery via ACK’s:

i) Update Packets

ii) Query Packets

iii) Reply Packets

Hello and Acknowledgments (ha!) packets do not utilize RTP, and thus do not require acknowledgement. 

 

EIGRP Route States 

An EIGRP route can exist in one of two states, in the topology table:

(i) Active state - A route is placed in an Active state when the Successor and any Feasible Successors fail, forcing the EIGRP to send out Query packets and reconverge. Multiple routes in an Active state indicate an unstable EIGRP network. If a Feasible Successor exists, a route should never enter an Active state.

(ii) Passive State - A Passive state indicates that a route is reachable, and that EIGRP is  fully  converged. A stable EIGRP network will have all routes in a Passive state.

Routes will become Stuck-in-Active (SIA) when a router sends out a Query packet, but does not receive a Reply packet within three minutes. In other  words, a route will become SIA if EIGRP fails to re-converge.  

To view the current state of routes in the EIGRP topology table: 

Router# show ip eigrp topology 

To view only active routes in the topology table:
Router# show ip eigrp topology active 

EIGRP Metrics (Check)

EIGRP can utilize 5 separate metrics to determine the best route to a destination: 

(i) Bandwidth (K1) – Slowest link in the route path, measured in kilobits

(ii) Load (K2) – Cumulative load of all outgoing interfaces in the path, given as a fraction of 255

(iii) Delay of the Line (K3) – Cumulative delay of all outgoing interfaces in the path in tens of  microseconds

(iv) Reliability (K4) – Average reliability of all outgoing interfaces in the path, given as a fraction of  255.

(v) MTU (K5) – The smallest Maximum Transmission Unit in the path. The MTU value is actually  never used to calculate the metric.

By default, only Bandwidth and Delay of the Line are used. This is identical to IGRP, except that EIGRP provides a more granular metric by multiplying the bandwidth and delay by 256. Bandwidth and delay are determined by the interfaces that lead towards the destination network.  

By default, the full formula for determining the EIGRP metric is: 

[10000000/bandwidth + delay] * 256 

Configuring EIGRP Metrics 

EIGRP allows us to identify which metrics the protocol should consider, using the following commands: 
Router(config)# router eigrp 10
Router(config-router)# metric weights 0 1 1 1 0 0 

The first command enables the EIGRP process for Autonomous System 10. The second actually identifies which EIGRP metrics to use. The first number  (0) is for Type of Service, and should always be zero. The next numbers, in order, are K1 (1), K2 (1), K3 (1), K4 (0), and K5 (0). Thus, we are instructing EIGRP to use bandwidth, load, and delay to calculate the total metric, but not reliability or MTU. 

Our formula would thus be: 

[K1 * bandwidth * 256 + (K2 * bandwidth) / (256 - load) + K3 * delay * 256]

The actual values of our metrics (such as bandwidth, delay, etc.) must be configured indirectly. We can adjust the bandwidth of an interface: 

Router(config)# int s0/0
Router(config-if)# bandwidth 64000
Router(config-if)# ip bandwidth-percent eigrp 10 30 

(This command does not actually dictate the physical speed of the interface. It merely controls how EIGRP considers this interface. Best practice is to set the bandwidth to the actual physical speed of the interface) 

The ip bandwidth-percent eigrp command limits the percentage of bandwidth EIGRP can use on an interface. The percentage is based on the configured bandwidth value. By default, EIGRP will use up to 50% of the bandwidth of an interface. The above command adjusts this to 30% for Autonomous System 10. 

If adjustments to the EIGRP metric need to be made, the delay metric (in tens of microseconds) on an interface should be used:
Router(config)# int s0/0
Router(config-if)# delay 10000

Metric settings must be identical on the connecting interfaces of two routers; otherwise they will not form a neighbor relationship.

Configuring Basic EIGRP 

Routing protocol configuration occurs in Global Configuration mode. On Router A, to configure EIGRP, we would type:
RouterA(config)# router eigrp 10 
RouterA(config-router)# network 172.16.0.0 
RouterA(config-router)# network 10.0.0.0
The first command, router eigrp 10, enables the EIGRP process. The “10” indicates the Autonomous System number that we are using. The Autonomous System number can range from 1 to 65535.
Only other EIGRP routers in Autonomous System 10 will form neighbor adjacencies and share updates with this router. 
The network statements serve two purposes in EIGRP:

• First, they identify which networks you wish to advertise to other EIGRP routers (similar to RIP).

• Second, they identify which interfaces on the local router to attempt to form neighbor relationships out of (similar to OSPF). 

Prior to IOS version 12.0(4), the network statements were classful, despite the fact that EIGRP is a classless routing protocol. For example, the above network 10.0.0.0 command would advertise the networks of directly connected interfaces belonging to the 10.0.0.0/8 network and its subnets. It would further attempt to form neighbor relationships out of these interfaces.
IOS version 12.0(4) and later provided us with more granular control of our network statements. It introduced a wildcard mask parameter, which allows us to choose the networks to advertise in a classless fashion:
RouterA(config)# router eigrp 10 
RouterA(config-router)# network 172.16.0.0 0.0.255.255 
RouterA(config-router)# network 10.1.4.0 0.0.0.255  

EIGRP Passive Interfaces

It is possible to control which router interfaces will participate in the EIGRP process. Just as with RIP, we can use the passive-interface command.  

Note:- The passive-interface command works differently with EIGRP than with RIP or IGRP. EIGRP will no longer form neighbor relationships out of a “passive” interface, thus this command prevents updates from being sent or received out of this interface:

RouterC(config)# router eigrp 10

RouterC(config-router)# network 10.4.0.0
RouterC(config-router)# network 10.2.0.0
RouterC(config-router)# passive-interface s0

Router C will not form a neighbor adjacency with Router B.
We can configure all interfaces to be passive using the passive-interface default command, and then individually use the no passive-interface command on the interfaces we do want neighbors to be formed on: 

RouterC(config)# router eigrp 10
RouterC(config-router)# network 10.4.0.0
RouterC(config-router)# network 10.2.0.0
RouterC(config-router)# passive-interface default
RouterC(config-router)# no passive-interface e0

 

Note:- The passive-interface command will prevent EIGRP (and OSPF) from forming neighbor relationships out of that interface. No routing updates are passed in either direction.

EIGRP Auto-Summarization  

EIGRP is a classless routing protocol that supports Variable Length Subnet Masks (VLSMs).  EIGRP is a classless routing protocol that supports Variable Length Subnet Masks (VLSMs). The above example would pose no problem for EIGRP.

However, EIGRP will still automatically summarize when crossing major network boundaries. 

When Router A sends an EIGRP update to Router B via Serial0, by default it will still summarize the 10.1.0.0/16 network to 10.0.0.0/8. This is because the 10.1.0.0/16 and 192.168.123.0/24 networks do not belong to the same major network. Likewise, the 66.115.33.0/24 network will be summarized to 66.0.0.0/8.  

An auto-summary route will be advertised as a normal internal EIGRP route. The best metric from among the summarized routes will be applied to this summary route. 

The router that performed the auto-summarization will also add the summary route to its routing table, with a next hop of the Null0 interface. This is to prevent routing loops. 

Auto-summarization can be disabled by following command: 

RouterA(config)# router eigrp 10

RouterA(config-router)# no auto-summary

(The no auto-summary command will prevent Router A from summarizing the 10.1.0.0/16 and 66.115.33.0/24 networks)  

EIGRP Load-Balancing 

By default, EIGRP will automatically load-balance across equal-metric routes (four by default, six maximum). EIGRP also supports load-balancing across routes with an unequal metric.  

We established that Router A would choose the route through Router D as its Feasible Distance to the destination network. The route through Router B became a Feasible Successor.  

By default, EIGRP will not load-balance between these two routes, as their metrics are different (11 through Router D, 16 through Router B). We must use the variance command to tell EIGRP to load-balance across these unequal-metric links:  

RouterA(config)# router eigrp 10
RouterA(config-router)# variance 2
RouterA(config-router)# maximum-paths 6  

The variance command assigns a “multiplier,” in this instance of 2. We multiply this variance value by the metric of our Feasible Distance (2 x 11 = 22). Thus, any Feasible Successors with a metric within twice that of our Feasible Distance (i.e. 12 through 22) will now be used for load balancing by EIGRP.  

Note:- Only Feasible Successors can be used for load balancing, not Possibilities (such as the route through Router C).

The maximum-paths command adjusts the number of links EIGRP can loadbalance across.  

Some basic and useful commands of  EIGRP

To debug EIGRP in realtime: 

Router# debug eigrp neighbors
Router# debug eigrp packet
Router# debug eigrp route
Router# debug eigrp summary 

To view the EIGRP Neighbor Table: 

Router# show ip eigrp neighbor 

To view the EIGRP Topology Table, containing all EIGRP route information: 

Router# show ip eigrp topology

To view information on EIGRP traffic sent and received on a router:  

Router# show ip eigrp traffic  

  
To view the bandwidth, delay, load, reliability and MTU values of an interface:

Router# show interface s0  

To view the IP routing table: 

Router# show ip protocols

To view a specific route within the IP routing table: 

Router# show ip route 10.3.0.0 

 

END