Sam, Thanks for the explanation. it does make a lot of since of what you said .. I am also looking for expalanation with netwok Id and subnet . almost like to one you see on the router when you do sho ip route .. it mentioned summarization are in effect ,, Thanks for your time again..

Ok, for an example with networks and subnets lets try this: assume that you have a network that has the following subnets in it:

172.16.0.0/24

172.16.1.0/24

172.16.2.0/24

172.16.3.0/24

172.16.4.0/24

172.16.5.0/24

172.16.6.0/24

172.16.7.0/24

172.16.8.0/24

172.16.9.0/24

172.16.10.0/24

172.16.11.0/24

172.16.12.0/24

172.16.13.0/24

172.16.14.0/24

172.16.15.0/24

and if you were running a dynamic routing protocol like EIGRP there would be 16 entries in your routing table. This maximizes the specific information in the route table assures accuracy in the routing decision.

But you could generate a summary route:

172.16.0.0/20

with the summary route you would have a single entry in the routing table, (less specific information in the routing table) but it would still get you to those 16 subnets.

As Sam points out there are several advantages in using summarization. For one thing it takes less room in the routing table and so you save on memory utilization, and you save on CPU cycles to maintain the routing table. And as Sam points out it can make the routing table more stable with fewer routing table updates. For example in the first method (all subnets in the routing table) if subnet 172.16.3.0 went down then there would be a routing table update to indicate that it was down. And when it came back up there would be another routing table update to indicate that it was back up. But with summarization when the subnet goes down you do not need a routing table update because the summary route is still valid. And when the subnet comes back up you do not need a routing table update because the summary route is still valid.

HTH

Rick

rick why did you use /20 as the route summary,, Thank you

Thank you all for taking the time and explaining in details the role of route summarization. very helpfull info.

rick how did you come up w /20 as the route summary,, Thank you

U r d Man, well explained thanks. got it now ..

I am glad that you got it now. It can become a complex topic and one that is quite important. Thank you for using the rating system to indicate that your question was resolved (and thanks for the rating). It makes the forum more useful when people can read a question and can know that they will read responses which did help to resolve the question.

HTH

Rick

Rick,

I have a follow-on question to this...

Using your example of summarizing 16 subnets with one summary route, what if the summary covers networks which do not exist, (planned for the future, but not yet implemented)?

If using EIGRP to advertise these specific networks, as well as the summary route, other routers will send traffic destined for any of the networks in the summary to the router advertising the summary. Then, I would assume, the route to null0 on this summarizing router would be used to drop packets destined to the non-existing networks contained in the summary, since a more specific route to the network does not exist. Is this correct? What potential problems could this cause?

I ask because it is troublesome to change the summary route statement(s) every time a new network is added behind the summarizing router. Changing the summary route statement will reset the EIGRP peering, which is disruptive in an active network.

We have active networks which are not all contiguous, but they all conform to an addressing plan per area. For example, all locations in Area 14 use 10.14.xx.xx/24. So, even though there are only 20 networks in Area 14, it would be safe to advertise 10.14.0.0/16 from the border (summary) router, since all 10.14.xx.xx/24 networks are only reachable through this border or summary router. However, there are many subnets implied within the summary which do not exist, and may never exist. So, is this large summary address potentially harmful to the network? Other than routing 10.14.xx.xx/16 traffic to the border router, only for it to drop the traffic, are there any dangers?

Thanks in advance for your response.

Ron Buchalski

Ron

Your review of how EIGRP deals with summary routes is exactly correct.

As long as you are dealing with a routing protocol that will create the null0 route for the summary (or if you manually create the null0 route), then I do not believe that there is any danger in creating a summary route that includes some subnets that do not exist (and may never exist). Without the null0 route there is a possibility that your router will advertise the summary address block, that some router will forward a packet to you for a subnet that does not exist, that you might forward the packet using your default route (since you do not have a route to that subnet), and the next hop router may forward it back to you (creating a loop). (though since the destination does not exist a loop is just another way to discard the packet and we could argue that the loop here does not damage anything)

In your case I believe that the advantages of summarizing the 10.14.0.0/16 far outweigh any downside of summarizing and advertising subnets that do not exist.

As I see it, the downside of summarizing a block when some subnets in the block do not exist is that some extra traffic will be generated (sending packets to the summarizing router who will drop them rather than dropping the packet at the original router). To me the extra traffic is not a problem and the advantages of summarization make it worth it (smaller routing table, less memory and fewer CPU cycles consumed for the routing table, greater stability in the network, fewer routing updates). Your opinion of what constitutes a problem or danger may vary.

HTH

Rick

Rick,

Thank you for confirming what I suspected.

Using EIGRP, and having put a summary address statement on the appropriate interfaces of the area aggregation router as a test, I find the following route on the aggregation router:

xxx-MainR#sh ip route 10.14.0.0

Routing entry for 10.14.0.0/16

Known via "eigrp 1234", distance 5, metric 28160, type internal

Redistributing via eigrp 1234

Routing Descriptor Blocks:

* directly connected, via Null0

Route metric is 28160, traffic share count is 1

Total delay is 100 microseconds, minimum bandwidth is 100000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 9/255, Hops 0

xxx-MainR#

One hop away, I find:

xxx_WANR#sh ip route 10.14.0.0

Routing entry for 10.14.0.0/16

Known via "eigrp 1234", distance 90, metric 130816, type internal

Redistributing via eigrp 1234

Last update from 10.214.100.2 on GigabitEthernet3/2.250, 13:28:03 ago

Routing Descriptor Blocks:

* 10.214.100.2, from 10.214.100.2, 13:28:03 ago, via GigabitEthernet3/2.250

Route metric is 130816, traffic share count is 1

Total delay is 110 microseconds, minimum bandwidth is 20000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 4/255, Hops 1

xxx_WANR#

So, summarization is happening as it should, and traceroute to a non-existent network reveals:

xxx_WANR#trace 10.14.90.254

Type escape sequence to abort.

Tracing the route to 10.14.90.254

1 10.214.100.2 8 msec 12 msec 8 msec

2 10.214.100.2 !H * !H

xxx_WAN#

I understand that this may lead to some additional traffic being routed across the WAN links to the summarizing router, only to be dropped. A better solution would be to have a 10.0.0.0/8 route to null0 in the core of the network, so any traffic passing through the core, destined for non-existent subnets within 10.x.x.x, would be null routed at the core. This would also prevent any traffic destined for non-existent 10.x.x.x networks from following default to our internet edge routers.

I'm a little hesitant to implement these null routes at the core until I can verify that they won't cause any other problems.

Thanks again,

Ron Buchalski

Ron

Perhaps there is some aspect of your environment that I am not understanding. But your point about configuring a 10.0.0.0/8 null route at the core is not clear to me. Would traffic come across the WAN links to the summarizing router on its way to the core? So I am not clear how the 10.0.0.0/8 helps deal with the issue of extra traffic (consuming bandwidth before it is dropped). But certainly a 10.0.0.0/8 would be effective at preventing unknown subnets of 10.0.0.0 being forwarded toward the default route (assuming that the default route is configured on the core).

Only someone familiar with your network and its topology can determine if the summary route could cause any other problem.

HTH

Rick