STEEM Course: IPv4 Routing Primer (Part 7)

over 4 years ago

Hello and welcome! It's been a while since I've created any technical content, but I'm looking to apply more effort in that area going forward. I have been working on a video course regarding Routing for IP version 4, and I've decided to post my slides and scripts exclusively on STEEM as I go along. This content in this form is a STEEM exclusive. I appreciate any feedback or suggestions, or if you are new to the world of computer networking, I hope you enjoy them! If you are brand new to the topic, I recommend that you review my previous course posted on STEEM titled IP Version 4 Addressing And Subnetting Deep Dive.

Here is part 7 of a multi-part series. In this section, we will dive deeper into Enhanced Interior Gateway Routing Protocol (EIGRP). How many parts will there be? I have no idea because I am posting them as I go along. This and all @steempeak initiated posts will have a 5% beneficiary set to @null to help fight inflation.

The EIGRP topology table is where EIGRP stores its routes. The successor route is the best route to a given destination based upon the metric. It will be the one installed into the routing table. If the there are multiple routes to the same destination with identical metrics, EIGRP will load balance them.

The EIGRP topology table can also store backup routes with less desirable metrics. These are called feasible successor routes. With a feasible successor present, EIGRP can transition rapidly to a backup path. Think of a feasible successor as a hot backup. In order for a route to become a feasible successor, the feasibility condition must be met. Routes not meeting the feasibility condition could be considered a cold backup.

In order to better explain the feasibility condition, we must learn how EIGRP measures the distance for a route.

EIGRP uses two distances to determine if a route meets the feasibility condition.

The first one is reported distance. Reported distance is the metric of a specific path being reported by an upstream neighbor. In the example R2 is reporting to R1 that the distance to 10.5.55.0/24 is 500. This is combined metric off all links on the path as seen by R2 leading to the destination network.

The next distance used is the feasible distance. The feasible distance is the metric of the entire path, including the link to the upstream neighbor. In the example R1 has a feasible distance of 600 to 10.5.55.0/24.

R1 can use these numbers calculated for various backup routes to decide if they meet the feasibility condition and are eligible to become a feasible successor (backup route).

Now that we are aware of the distances EIGRP uses to determine if a route meets the feasibility condition, let’s describe the condition itself. So we already know the path with the best end-to-end metric (feasible distance) will become the successor. In order to determine if there is a loop-free backup available we must compare the reported distance of potential backups to the feasible distance of the current successor route. Specifically, the reported distance must be LESS THAN the feasible distance of the successor.

Backup routes not meeting the feasibility condition can eventually be used, but they must be discovered through an EIGRP query process after there are no longer any successor or feasible successor routes available. More on the EIGRP query process later. Let’s take a look at an example of a feasibility condition calculation.

For our example, we are using R1 as our reference point, and have 3 possible paths to 10.5.55.0/24 via R2, R3, and R4.

The path via R3 has the lowest feasible distance to the 10.5.55.0/24 network, therefore it will become the successor route. The feasibility condition will be applied to determine if there is a valid backup route. In this case we have two possible backup routes. The feasibility condition states that in order to become a feasible successor, the reported distance must be less than the feasible distance of the current successor route. The current successor route via R3 has a feasible distance of 300. The path via R2 has a reported distance of 400, therefore it is ineligible to become the feasible successor. The path via R4 has a reported distance of 200, which is less than the feasible distance of the successor, therefore it IS eligible to become the feasible successor. In this case, if both the sucessor and feasible successor lose connectivity to R1, R1 will need to perform a query in order to discover the path via R2. Let’s take a closer look at EIGRP queries.

When an EIGRP router loses its successor route, and there is no feasible successor available, it must utilize a query process to determine if there are any available backup routes. When the query process occurs, the route will go into an active state, and the router will generate a query and send it to all its directly connected neighbors. From there, the query is passed from router to router within the entire EIGRP autonomous system.

Each router receiving the query should return a response indicating whether or not a backup is available. If neighbor router fails to generate a response, the route can become ’stuck in active’, and the neighbor relationship is reset.

Good EIGRP design means prevention and minimization of queries on your network.

The first and most obvious way to prevent queries, is to always have a feasible successor present. This is done by ensuring a backup path is available, and it meets the feasibility condition by design.

In the absence of always having a feasible successor, you can reduce the impact of EIGRP queries through a number of strategies. These include route summarization, passive interfaces, and stub networks.

Route summarization will prevent queries being propagated for routes that are covered by the summary. Summarization is simply combining multiple component routes into a single summary. For example 10.5.5.0/24 and 10.5.65.0/24 could be summarized using 10.5.0.0/16.

Passive interfaces prevent the EIGRP process from running on the interface and prevent any EIGRP traffic from being generated (including queries).

Stub routing can be used to prevent queries from being generated because a query will not be sent to a router configured as a stub. Let’s describe stub routers in more detail.

A stub is a part of the network that traffic doesn’t transit through to get to other networks. If traffic going to a router is only destined for IP addresses hosted by that router, it can be considered a stub.

In EIGRP, networks minimize the amount of information needed to communicate, because in most cases, a stub only requires a default route in order to operate. It does not need to be made aware of the rest of the network. By default stubs only share their own connected and summary routes, but can be configured to share more.

A stub router will not process EIGRP queries, so they can help speed up the overall query process on a network by limiting its scope.

In our example, we have a simple hub-and-spoke network. The hub is R1, meaning it is the aggregation point for all other routers. R2, R3, and R4 would be considered spoke networks. Because the spokes do not allow transit to any other networks, they can be considered stub networks.

If you are running a small to medium-sized Cisco-only enterprise network, EIGRP is a great solution. It is easy to configure, and high performance with the default configuration. It is also very easy to tune and influence routing behavior using summarization, stub routing, and filtering.

If you plan on running a multi-vendor environment, or plan to switch vendors at some point, EIGRP might not be the best choice.

Thanks for viewing! I hope this subject was of some interest to you. In the next part, we will explore the Open Shortest Path First (OSPF) protocol.

stem steemstem palnet technology learning networking

0.000

6 comments

@bearbear613 74

over 4 years ago

Your post has been curated by the bitcoin myk project. Tokens are available for this account you can trade for steem at: https://steem-engine.com/. Join our curation priority list to earn more tokens by registering at:

http://www.bitcoinmyk.com/register/

Visit our discord at: https://discordapp.com/channels/523971711733858364/523971711733858366

Bitcoin MYK
admin
Register - Bitcoin MYK
This post earned 50 BTCMYK

0.000

@stem.curate 50

over 4 years ago

Hello,

Your post has been manually curated by a @stem.curate curator.

Supporting Steemians on STEMGeeks

We are dedicated to supporting great content, like yours on the STEMGeeks tribe.

If you like what we are doing, please show your support as well by following our Steem Auto curation trail.

Please join us on discord.

0.000

@carloserp-2000 69

over 4 years ago

Great material, friend. For the next one leave some references about the topic, that will help you to get more support in votes from steemstem.

0.000

@joshman 74

over 4 years ago

You mean additional references? Please elaborate.

I am a certified expert (CCIE) with over 20 years of experience, and the subject matter is common knowledge within the field of networking.

0.000

@carloserp-2000 69

over 4 years ago

Great that you're an expert. And the references are important even if the material is 100% of your authorship...it's a requirement to receive more support.

0.000

@steemstem 74

over 4 years ago

This post has been voted on by the SteemSTEM curation team and voting trail. It is elligible for support from @curie and @minnowbooster.

If you appreciate the work we are doing, then consider supporting our witness @stem.witness. Additional witness support to the curie witness would be appreciated as well.

For additional information please join us on the SteemSTEM discord and to get to know the rest of the community!

Please consider using the steemstem.io app and/or including @steemstem in the list of beneficiaries of this post. This could yield a stronger support from SteemSTEM.

0.000