EIGRP and Summarization

Hey guys,

Wondering if someone could help me understand EIGRP when auto-summary is in effect.

Here is the discontiguous topology I am working with.

10.1.1.0/24 and 10.1.2.0/24

R1 ---- 172.16.1.0 ---- R2

10.1.3.0/24 and 10.1.4.0/24

In this case, 2 subnets of the 10.0.0.0 network are to the left of R1, and another 2 subnets
are to the right of R2. The subnets behind R1 cannot reach the subnets behind R2, and vice-versa.

I have enabled eigrp with auto-summarization.

I understand that R1 will summarize the 2 subnets into 10.0.0.0/8 before advertising out to R2.
R2 will do the same.

Here is my question:

R2 will receive an update from R1 stating 10.0.0.0/8. I have verified this with a capture.
Why doesn't R2 install a route to 10.0.0.0/8 into its routing table with the next hop pointing to R1?
This way, it will have more specific routes to the 2 connected subnets in its routing table, but will use
the summary route for all other 10. addresses for which it does not have a more specific match.

I know that discontiguous networks are a problem when using a protocol such as RIP Ver1, but it appears that
discontiguous subsets are also a problem here when using a Classless protocol such as EIGRP.
EIGRP is classified as a Classless Routing protocol, but its Classless behaviour seems to only come
into effect when no auto-summary is used.

Using no auto-summary fixes the issue mentioned above.

Any thoughts?

Find more posts tagged with

SAVE $250 on Your CISCO Boot Camp — Use Code "EXAM26"

Exclusively for TechExams members for Infosec Boot Camps starting before April 30, 2026

View CISCO Boot Camps

Comments

wrwarwick

Looks like this is working as intended. Does R2 see the 10.0.0.0/8 network as directly connected?

As to the classless/classful issue, EIGRP pretty much acts like a classful protocol if you do not turn off auto summarization. Any reason why you are leaving it on? Just for labbing I assume?

SharkDiver

When "auto-summary" is on, R2 will receive a route to 10.0.0.0/8 from R1. This route will be via EIGRP and will have an Administrative Distance of 90. The connected 10.0.0.0/8 route will have an Administrative Distance of 0. Therefore, only the connected route will be placed into the routing table.

If you do a "show ip eigrp topology", you should see that the other route has been learned, but isn't being used.

up2thetime

Here is the routing table on R2:

D 172.16.0.0/16 is a summary, 00:10:54, Null0
C 172.16.1.0/24 is directly connected, Serial0/0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
C 10.1.3.0/24 is directly connected, Serial0/1
D 10.0.0.0/8 is a summary, 00:10:54, Null0
C 10.1.4.0/24 is directly connected, Serial0/2

Since R2 will auto-summarize 10.1.3.0 and 10.1.4.0 into 10.0.0.0/8, then R2 will need
to add this summary route into its table with next hop being Null0.

At the same time, R1 is also advertising 10.0.0.0/8 to R2.
However R2 will not accept the advertised route from R1 because R2 notices that
it already has a route to 10.0.0.0/8 through Null0. This leads me to believe that the reason that R2 will not accept the route advertised by R1 is because R2 already has a better route to 10.0.0.0/8, even though the route is through Null0. Is this correct?

And yes SharkDiver, you are correct. The route does show up in the topology table (only when show ip eigrp topology all-links is used).

Without using keyword all-links:
P 10.0.0.0/8, 1 successors, FD is 2169856
via Summary (2169856/0), Null0

With using keyword all-links:
P 10.0.0.0/8, 1 successors, FD is 2169856, serno 6
via Summary (2169856/0), Null0
via 172.16.1.1 (2681856/2169856), Serial0/0

I guess we can see that the route advertised by R1 does not meet the Test of Feasibility because the Reported Distance is not LESS than R2's Feasible Distance. R2 has a FD of 2169856, and R1 is reporting 2169856. They are the same. Since 2169856 is not LESS than 2169856, it will not be included in R2s topology table.

Correct…?

SharkDiver

I hadn't thought of the feasibility condition. Good point.

I would say that the main reason that the route through R1 is not in the routing table on R2, is in fact, the feasibility condition.

The feasibility condition keeps that route from being added to the EIGRP topology table and, therefore, keeps it from being added to the routing table.

I wasn't thinking of the routes as being redundant links, because they aren't, but the router thinks they are.

Eildor

up2thetime wrote: »

EIGRP is classified as a Classless Routing protocol, but its Classless behaviour seems to only come
into effect when no auto-summary is used.

I believe you have answered your own question. EIGRP by default acts like a classful routing protocol, and therefore summarizes at classful boundaries.