My router config as follows:
ip address 10.1.0.1 255.255.0.0
ip address 10.2.0.1 255.255.0.0
router eigrp 100
The router is performing auto-summarization. Let's say, if it receives advertisement for 192.168.1.64/26 (an internal EIGRP route) on interface Fas0/0, will it auto-summarize it to major network 192.168.1.0/24 when advertising it out interface Fas0/1?
And what about if 192.168.1.64/26 is an external EIGRP route?
by default eigrp is a classfull routing protocol, so you dont need to type auto-summary it s there by default, since under your router eigrp 100 you configured the network 10... the router will run eigrp on all interface in the 10. network so the route 192.168.1.64/26 that is received from fa0/0 will be advertised through fa0/1 but as a summary to the classful network 192.168.1.0/24 no mater if it s an internal or an external route.
but it s not recommanded to use auto-summary, since you have the flexibility of summarising by interface basis, in that case the router automatically create a route toward the null interface and keep in the routing table the more specific routes and advertise only the summary and it uses the lowest metric of the more specific routes as the metric of the summary route.
do rate if it does help
"EIGRP will not auto−summarize external routes unless there is a component of the same major network that is an internal route.
However, if you reconfigure the link between Routers Two and Three to 22.214.171.124/26, and add network statements for this network on Routers Two and Three, the 126.96.36.199/24 auto−summary is then generated on Router Two."
The above paragraph is an excerpt from the white paper
This white paper doesn't tell if a router will auto-summarize two internal routes ( belong to the same classfull network) that is receives from other routers. I do a test and the result is the same as external routes. That is, if you want the auto-summarization happen, two requirements must meet:
1.There is at least one component of this classful network resides in this router. ( in other words, there is an interface assigned a ip address that is in the different subnet but in the same natwork as the received routes)
2. You add a network statement of this network to the "router eigrp" process.
For your case, add following command to your config:
int loopback 1000
ip address 192.168.1.129 255.255.255.192
! or any other ip address in the same network
router eigrp 100
This will make a summary route be generated.
Advertisement of this summary route is another story. For this case, it cross the classful network boundry (10.0.0.0 vs 192.168.2.0), so it will advertise this summery route to other router.
Hope this help
I will make the rules about autosummarization, internal and external, a bit easier to understand. :-)
EIGRP autosummarizes based on the network statements configured on the router. If you receive a route to 192.168.1.64/26, no matter whether it's internal or external, and your configuration only has network statements for 10 addresses, the router will not autosummarize to 192.168.1.0/24
On the other hand, any time you have multiple network statements in different major networks, EIGRP will autosummarize between those two major networks. You can verify this in the lab, using two routers. Configure one with one interface as 192.168.1.64/26, and another interface as 10.1.1.1/24. Configure EIGRP, and put on network 192.168.0.0 and 10.0.0.0, along with no auto-summary.
On the other router, have two interfaces both in the 10 network, and configure network 10.0.0.0, leaving auto-summary enabled. Check the local topology table, and you should not see any autosummary for the 192.168 address space.
Put in a network statement for 192.168.0.0, and you should see an autosummary pop up, although this router has no interfaces on the 192.168.0.0 network. At least, that's the way I remember it working, the last time I touched that code (it's been three or four years).
It's interesting to note that using wildcard bits doesn't impact autosummarization, either. We actually pull the wildcard bits off when figuring auto-summaries out. I don't recall how supernet network statements work, but I believe they don't matter, either, we walk the list of major nets under the supernet, and make things work right.
At any rate, autosummaries are done off the network statements, not the attached interfaces, so external or internal doesn't matter.
Hi Russ & SSLIN,
Thanks for your good response.
SSLIN mentioned we need a connected interface (on the same major net, i.e. 192.168.1.0) on the router performing the auto-summarization, besides the "network 192.168.1.0" statement.
I have no access to routers at this time. Will perform a lab at my soonest and feedback my results.
I'm having a senior moment. :-) I just checked in the lab, and there does need to be an interface in the major network locally connected for the autosummarization to occur.
I went back and took a look at the code, and it looks like the loop that walks the network statements only touches the network statement if there's a local interface referencing the network statement.
Thanks for your update. As a matter of fact, I have collected some data from the lab to support my plea on this issue. But, since you have updated it for us, I feel a great relief now.
Let alone the controversy we have reached an agreement, I found another strange problem I cannot explain:
The 10.0.0.0/8 network would not be auto-summerized (even though it has met all the requirements of auto-summerization) until the 192.168.1.0/24 was auto-summerized. Moreover, they were de-auto-summerized simultaneously when I removed the network statement on 192.168.1.0/24 or I removed the ip address of a connected interface on that network. Could you please explain for us why it behaved so? Is this a bug or not?
I have attached two files for your reference. R3 is the router advertising 192.168.1.64/26, and R4 receives this routes, doing some config cahnge, and make the auto-summerization to happen. I have typed some show and debug command on this router to make some interesting output. You can see all the config change and the sonsequrnt output frme this file.
It would be nice to get an answer from you and I hope it would not bother you too much
Okay, I finally made some time to go poke at the code this morning.... The way it works, now, is this (and yes, there have been changes--lots of changes--since the last time I was messing around in there).
For (each interface)
.For (each network statement)
..If (this IP address is not within this network statement)
...If (there is an interface running EIGRP within this network statement)
....Build an auto-summary out this interface
So, what you are seeing is normal--auto-summaries are built based on the network statements, but only if there's an interface in both the two major networks indicated by the network statements.
Thank you for answering my question even though you were busy then.
I followed up your code and now I finally understand what I have missed. The 10.0.0.0/8 will not be auto-summarized at the first time because, at that time, only ip addresses within 10.0.0.0/8 were configured on the interfaces. Even the summary routes was generated, it will have no chance to be advertised out.The router knows this point and thus will not generate the summary routes.
Before, I thought the router had one rule to generate summary routes. After the summary routes had been generated, it had another rule to determine whether advertise it or not.
Now, I know I was wrong for this point. You save my life!
Looking forward to learning more from you and wishing your seminar successful.
I finally manage to perform a lab on EIGRP auto summarization. Please see attached network diagram and results.
Cisco technote says: EIGRP performs an auto-summarization each time it crosses a border between two different major networks.
When I configured "auto-summary" on R6, the 10.1.2.0/24 route received from R9 is auto-summarized (to 10.0.0.0/8) out to R5. But not 192.168.1.64/26, which I expect to be auto-summarized too because I have the network 192.168.1.0 statement on R6.
After I added the following loopback address on R6,
ip address 192.168.1.129 255.255.255.192
R5's EIGRP routes are as follows:
R5#sh ip rou ei
D 10.0.0.0/8 [90/22562560] via 172.16.1.6, 10:42:50, FastEthernet0/0
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
[90/22690560] via 172.16.1.6, 10:42:45, FastEthernet0/0
D 192.168.1.0/24 [90/156160] via 172.16.1.6, 07:28:49, FastEthernet0/0
Still, 192.168.1.64/26 is not auto-summarized.
Please enlighten me.
When I changed the subnet between R6 and R9 to be on major net 192.168.1.0, this time the 192.168.1.64/26 route received from R9 is auto-summarized (to 192.168.1.0/24) out to R5, but not the 10.1.2.0/24 route.
I'm getting confused and unable to make a conclusion on how EIGRP performs auto-summarization of internal routes.
In your case, since the route exchanged between the 2 routers matches the major network of the interface between the 2 routers the route will be entered in the router receiving that route with the same subnet mask of the interface, its only summarized to the major network when it doesn't match the major network of the interface between the 2 routers.
HTH, please rate if it does help,
What else have you done for Cisco?
Hope you keep reading this forum,this is the kind of info that really helps us understanding routing in Cisco.
Not just memorizing stuff. Knowing how it was written is away better than reading some else book, where ppl whether read it or analized the behaviour of the routers.
"Hope you keep reading this forum,this is the kind of info that really helps us understanding routing in Cisco."
I normally watch for questions that I don't think others will be able to answer, rather than answering everything. I'm not always right, of course (witness this thread, in fact), but I can always go check things. :-)
As for what I've done, and what I do, gee, it's a long story. TAC/Hardware, TAC/Fast Track, TAC/Routing Protocols, Global Escalation for Routing Protocols and hardware architecture issues, IOS/XR Team (before it was called that), and now the Architect's Team, on Routing Design and Architecture.