Re: EIGRP auto-summary CCNA activity

marcin.kaczynski · ‎03-20-2017

Hi

My question concerns the activity in CCNA Routing&Switching online netacad course - module 3, chapter 8.1.1.9.

Scenario1 - why the second correct answer is 192.168.1.0/24? EIGRP performs auto-summarization each time it crosses a border between two different major networks. But this is not the case in Scenario1. According to me, it should be 192.168.1.0/30.

Scenario2 - it's clear.

Scenario3 - why there is no place for second answer 172.16.1.192/30?

Thanks in advance for your replies.

kwronszczyk · ‎03-18-2019

Dear Marcin,

hope you are doing well. Answering your questions, with auto-summary enabled EIGRP summarizes only on the boundary of classfull networks.

3rd scenario is correct as all interfaces belong to the same 'major classfull network' 172.16.0.0 so R1 won't perform auto-summarization and will advertise its connected networks with mask from its interface. 172.16.1.192/30 will not appear in the topology table of R2 as EIGRP router originated by R1, because it is connected to R2 and it will appear in the topology table as connected to R2.

1st scenario is partially correct. I think 172.16.0.0/16 is the only right answer. Here we have classfull network boundary so R1 will summarize 172.16.1.0/24 to class B major network 172.16.0.0/16 and advertise it on the boundary so it means only toward the R2. If there would be a EIGRP router connected to the 172.16.1.0/24 segment, R1 then should summarize 192.168.1.0/30 to 192.168.1.0/24 and advertise it toward this router.

marcin.kaczynski · ‎06-28-2019

Hello @kwronszczyk

Thanks for your explanation. But I think I found right answer. First of all, the question is misleading, becasue one step is what R1 will advertise to R2, and second what R2 will install to its topology table (eventually to its routing table, but it doesn't matter in this case). I did a lab for the 1st and 3rd question with the real Cisco IOS.

Scenario1 - R1 will advertise 172.16.0.0 /16 of course (auto-summarization and border major networks) AND ALSO 192.168.1.0 /30 but with metric of infinity, so R2 will install only 172.16.0.0 /16 to its topology table (and routing table), but 192.168.1.0 /30 will be simply discarded. Additionally R2 will also advertise 192.168.1.0 /30 with metric of infinity to R1, and in the same way R1 will not install it in its routing table.

A little output of R2:

R2#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(100)/ID(192.168.1.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P 172.16.0.0/16, 1 successors, FD is 409600
        via 192.168.1.1 (409600/128256), Ethernet0/1
P 192.168.1.0/30, 1 successors, FD is 281600
        via Connected, Ethernet0/1

R2#show ip eigrp events
Event information for AS 100:
1    10:27:50.472 NSF stale rt scan, peer: 192.168.1.1
2    10:27:50.471 Peer NSF restarted: 192.168.1.1 Ethernet0/1
3    10:27:50.446 Change queue emptied, entries: 1
4    10:27:50.446 Metric set: 172.16.0.0/16 metric(409600)
5    10:27:50.446 Update reason, delay: new if delay(Infinity)
6    10:27:50.446 Update sent, RD: 172.16.0.0/16 metric(Infinity)
7    10:27:50.446 Update reason, delay: metric chg delay(Infinity)
8    10:27:50.446 Update sent, RD: 172.16.0.0/16 metric(Infinity)
9    10:27:50.446 Route installed: 172.16.0.0/16 192.168.1.1
10   10:27:50.446 Route installing: 172.16.0.0/16 192.168.1.1
11   10:27:50.446 Find FS: 172.16.0.0/16 metric(Infinity)
12   10:27:50.446 Rcv update met/succmet: metric(409600) metric(128256)
13   10:27:50.446 Rcv update dest/nh: 172.16.0.0/16 192.168.1.1
14   10:27:50.446 Metric set: 172.16.0.0/16 metric(Infinity)
15   10:27:50.446 Ignored route, inaccessible: 192.168.1.0/24 metric(Infinity)
16   10:24:11.517 Rcv peer INIT: 192.168.1.1 Ethernet0/1
17   10:22:39.810 Rcv peer INIT: 192.168.1.1 Ethernet0/1
18   10:22:39.117 Conn rt change: 192.168.1.0/30 Ethernet0/1
19   10:22:39.117 Change queue emptied, entries: 1
20   10:22:39.117 Metric set: 192.168.1.0/30 metric(281600)
21   10:22:39.117 Update reason, delay: new if delay(Infinity)
22   10:22:39.117 Update sent, RD: 192.168.1.0/30 metric(Infinity)
23   10:22:39.117 Update reason, delay: metric chg delay(Infinity)
24   10:22:39.117 Update sent, RD: 192.168.1.0/30 metric(Infinity)
25   10:22:39.117 Route installed: 192.168.1.0/30 0.0.0.0
26   10:22:39.117 Find FS: 192.168.1.0/30 metric(Infinity)
27   10:22:39.117 Rcv update met/succmet: metric(281600) metric(0)
28   10:22:39.117 Rcv update dest/orig: 192.168.1.0/30 Connected
29   10:22:39.117 Metric set: 192.168.1.0/30 metric(Infinity)
30   10:22:39.117 Conn rt change: 192.168.1.0/30 Ethernet0/1

Scenario 3 - same thing. R1 will advertise 172.16.1.64 /26 AND 172.16.1.192 /30 with metric of infinity

kwronszczyk · ‎06-28-2019

You are right, question is not fully clear. I assumed that R1 send update AND R2 must install it to the topology table as router received form R1. In such case correct answers should be 172.16.0.0/16 (scenario 1) and 172.16.1.64/26 (scenario 3).

But in case of assumption where it comes routes that R1 advertises to R2 and no matter if they appear in R2's topology table, then your answer is correct.