EIGRP Overview
EIGRP is an advanced distance-vector protocol. There are a couple of items that cause it to be advanced:
- It uses a composite metric of bandwidth, load, delay, reliability, and MTU (really MTU is just a tiebreaker)
- It keeps a topology of what it has learned from neighbor routers in a topology database.
- EIGRP uses incremental updates instead of periodic updates
- Uses Reliable Multicast for Updates and Queries (Hellos, acknowledgements, and sequence TLVs are sent unreliably).
One thing to note about Distance Vector Protocols, as compared to Link State Routing Protocols, is the Distance Vector Routing Protocols, including EIGRP, allow for filtering and summarization at any point in the network.
EIGRP uses a combination of Split Horizon and Diffusing Update Algorithm (DUAL) to prevent routing loops. We will see later with DUAL and the Feasibility Condition that there is a mathematical way to determine if a path is loop free with EIGRP. The only downside is that at times the formula can indicate loops when one doesn’t really exist, which may cause alternate routes to not be used during primary path failures.
EIGRP, by default, will consume up to only 50% of the available bandwidth available on a link. It accomplishes this by pacing its packets based on the bandwidth that is configured on the interface. This is one reason it is always best to manually configure the bandwidth for what the line rate really is.
One important thing to remember is that with EIGRP, auto summarization is enabled by default on older versions of IOS. Disabling this feature should always be one of the first configuration tasks when setting up EIGRP.
Neighbor Relationships
EIGRP relies on neighbor relationships to provide reachability information. Once information is learned from a neighbor, a router assumes that information is valid as long as the neighbor relationship stays intact. If that information does change, then the neighbor is required to transmit a query, update, or other indication of the change.
These neighbor relationships are formed and maintained through hello packets. Each router periodically transmits Hello packets to multicast address 224.0.0.10. Two routers become neighbors when they see each other’s hello packets on a common network.
A Hold Timer indicates when a neighbor relationship is no longer valid. The Hold Timer in EIGRP is reset when an EIGRP router receives any type of packet from its neighbor, not just a Hello packet. EIGRP uses the network type in order to determine default Hello and Hold Time values:
- For all Point-to-point types - Default Hello = 5 seconds and Default Hold Time is 15 seconds
- For all links with a Bandwidth over 1 MB - the Default Hello = 5 seconds and Default Hold Time is 15 seconds
- For all multi-point links with a Bandwidth less than 1MB, the Default Hello = 60 seconds and Default Hold Time is 180 seconds.
The Hello and Hold timers are set independently - changing one does not automatically change the other. They are set on a per interface basis with the following commands:
R1(config-if)# ip hello-interval eigrp <seconds>
R1(config-if)# ip hold-time eigrp <seconds>
Unlike OSPF, the Hello and Hold timer values are carried in the Hello packets themselves. Because of this, routers will still form new neighbor relationships even with mismatched Hello and Hold Times.
When a network command activates an interface with EIGRP, that interface begins multicasting Hello packets. Any EIGRP routers that receive this sent multicast will begin attempting to form a neighbor adjacency with the sending router. An exception to this is if the neighbor command is used on a particular interface - one that command is used it disables multicast processing (inbound and outbound) for that interface and will only communicate via Unicast with the specified neighbor.
EIGRP does not build peer relationships over secondary addresses. All EIGRP traffic is sourced from the primary address of the interface.
Reliable Transport
By default, EIGRP sends updates and other information to multicast 224.0.0.10 and the associated multicast MAC address of 01-00-5E-00-00-0A. For multicast packets that are reliably delivered (Updates and Queries), EIGRP waits until a RTO (retransmission timeout) before beginning a recovery action. This RTO value is based off of the SRTT (smooth round-trip time) for the neighbor. These values can be seen in the show ip eigrp neighbor command.
If the router sends out a reliable packet and does not receive an Acknowledgement from a neighbor, the router informs that neighbor to no longer listen to multicast until it is told to once again. The local router then begins unicasting the update information. Once the router begins unicasting, it will try for 16 times or the expiration of the Hold timer, whichever is greater. It will then reset the neighbor and declare a Retransmission Limit Exceeded error.
Packet Types
EIGRP uses 5 packet types to handle session management and pass DUAL messages.
- HELLO Packets (including ACK)
- QUERY Packets (including SIA-Query)
- REPLY Packets (including SIA-Reply)
- REQUEST Packets
- UPDATE Packets
You definitely should remember this for the written exam.
UPDATE Packets
When a new neighbor is discovered, unicast UPDATE packets are used to transmit a full table to the new neighbor. In normal operation, UPDATE packets are multicast and are always sent reliably.
QUERY Packets
A QUERY Packet carries the DUAL QUERY message type and is sent by a router to advertise that a route is in ACTIVE state and the originator is requesting alternate path information from its neighbors.
An SIA-QUERY is sent to a neighbor in order to try to ascertain if the neighboring device is still attempting to converge on the active route. This enables an EIGRP router to determine if there is a communication issue with the neighbor or if it is simply still attempting to converge with downstream routers.
By sending an SIA-QUERY, the originating router may extend the effective active time by resetting the ACTIVE timer that has been previously set, thus allowing convergence to continue so long as neighbor devices successfully communicate that convergence is still underway.
The SIA-QUERY packet SHOULD be sent on a per-destination basis at one-half of the ACTIVE timeout period. Up to three SIA-QUERY packets for a specific destination may be sent, each at a value of one-half the ACTIVE time, so long as each are successfully acknowledged and met with an SIA-REPLY.
REPLY Packets
A REPLY packet carries the DUAL REPLY message type and is sent in response to a QUERY or SIA-QUERY packet.
An SIA-REPLY packet is the corresponding response upon receipt of an SIA-QUERY from an EIGRP neighbor. The SIA-REPLY packet will include a TLV for each destination and the associated vector metric in the topology table. The SIA-REPLY packet is sent after the entire received SIA-QUERY packet is processed.
HELLO Packets
When an EIGRP router is initialized, it will start sending HELLO packets out any interface on which EIGRP is enabled. HELLO packets, when used for neighbor discovery, are normally sent multicast addressed.
Internal vs External Routes
Internal routes will always be preferred in EIGRP over external routes.
Internal Routes are tagged with the following information:
- Router ID of the EIGRP router that originated the route.
- Configurable administrator tag.
External Routes are tagged with the following:
- Router ID of the EIGRP router that redistributed the route.
- AS number where the destination resides.
- Configurable administrator tag.
- Protocol ID of the external protocol.
- Metric from the external protocol.
- Bit flags for default routing.
Queries
When a topology change occurs, EIGRP actively searches for an alternative path to any destinations impacted by the change. EIGRP searches for these alternate paths by sending query packets to all its neighbors, asking them whether they know of a different path to the destination. Queries are sent to all neighbors except the ones that advertised the active route. Before queries are sent, Dull will test for Feasible Successors and will use any it finds in order to avoid any unnecessary recalculation.
Queries may cascade through a network, stopping only when one of there conditions is met:
- an alternative path is found
- the end of the network is reached
- information about the network that is the subject of the query is unknown
The RFP states “A diffusing computation grows by querying additional routers for their current RD to the affected destination, and it shrinks by receiving replies from them.”
When a router receives a query, it may respond with one of three answers:
- If the router receives a query about a route and has an alternative path that doesn’t go through the router asking the question, the router will immediately answer with the metric it uses to reach the target, and the QUERY is not propogated
- If the router receives a query and has no one else to ask, it immediately replies with an answer of infinity
- If the router receives a query about a route not contained in its topology table, it immediately replies with an answer of infinity
When a router sends a query to its neighbors, it sets a timer for approximately 3 minutes and must receive replies to all queries before the timer expires. If the timer expires, the route is considered Stuck in Active (SIA) and the peering with the neighbor that didn’t answer is reinitialized. This can cause a lot of disruption on the network.