Lesson Contents
Route summarization is a method where we create one summary route that represent multiple networks/subnets. It’s also called route aggregation or supernetting.
Summarization has a number of advantages:
- Saves memory: routing tables will be smaller which reduces memory requirements.
- Saves bandwidth: there are less routes to advertise so we save some bandwidth.
- Saves CPU cycles: less packets to process and smaller routing tables to work on.
- Stability: Prevents routing table instability due to flapping networks.
There are also some disadvantages to summarization:
- Forwarding traffic for unused networks: a router will drop traffic when it doesn’t have a matching destination in its routing table. When we use summarization, it’s possible that the summary route covers networks that are not in use. The router that has a summary route will forward them to the router that has advertised the summary route.
- Sub-optimal routing: routers prefer the path with the longest prefix match. When you use summaries, it’s possible that your router prefers another path where it has learned a more specific network from. The summary route also has a single metric.
This lesson doesn’t cover how to calculate summary routes. If that’s what you want to learn, take a look here.
It’s best to see everything I described above in action. Let’s take a look at some routers.
Configuration
This is the topology we will use:
For now, we only need two routers. R1 has four loopback interfaces that we will advertise in RIP. I’ll show you a “before” and “after” of route summarization.
Without Route Summarization
Let’s configure RIP so that all loopback interfaces are advertised:
R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#no auto-summary
R1(config-router)#network 172.16.0.0
R1(config-router)#network 192.168.12.0
R2(config)#router rip
R2(config-router)#version 2
R2(config-router)#no auto-summary
R2(config-router)#network 192.168.12.0
Let’s enable a debug so that we can see what is going on behind the scenes:
R1 & R2
#debug ip rip
RIP protocol debugging is on
Here’s what we will see:
R1#
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1 (192.168.12.1)
RIP: build update entries
172.16.0.0/24 via 0.0.0.0, metric 1, tag 0
172.16.1.0/24 via 0.0.0.0, metric 1, tag 0
172.16.2.0/24 via 0.0.0.0, metric 1, tag 0
172.16.3.0/24 via 0.0.0.0, metric 1, tag 0
R1 is advertising four different networks. R2 receives them:
R2#
RIP: received v2 update from 192.168.12.1 on GigabitEthernet0/1
172.16.0.0/24 via 0.0.0.0 in 1 hops
172.16.1.0/24 via 0.0.0.0 in 1 hops
172.16.2.0/24 via 0.0.0.0 in 1 hops
172.16.3.0/24 via 0.0.0.0 in 1 hops
The more information we advertise, the more bandwidth we require and more CPU cycles are required to process them. Of course, four networks on a Gigabit interface are no problem but in larger networks, there might be thousands or hundred of thousands of networks that are advertised.
Let’s check R2:
R2#show ip route rip
R 172.16.0.0/24 [120/1] via 192.168.12.1, 00:00:11, GigabitEthernet0/1
R 172.16.1.0/24 [120/1] via 192.168.12.1, 00:00:11, GigabitEthernet0/1
R 172.16.2.0/24 [120/1] via 192.168.12.1, 00:00:11, GigabitEthernet0/1
R 172.16.3.0/24 [120/1] via 192.168.12.1, 00:00:11, GigabitEthernet0/1
R2 stores all networks in its routing table which requires memory.
Let’s talk about stability. Let me show you what happens when we shut one of the loopback interfaces on R1:
R1(config)#interface loopback 0
R1(config-if)#shutdown
As soon as this happens, R1 will send a triggered update to R2:
RIP: sending v2 flash update to 224.0.0.9 via GigabitEthernet0/1 (192.168.12.1)
RIP: build flash update entries
172.16.0.0/24 via 0.0.0.0, metric 16, tag 0
R2 receives this update:
R2#
RIP: received v2 update from 192.168.12.1 on GigabitEthernet0/1
172.16.0.0/24 via 0.0.0.0 in 16 hops (inaccessible)
After awhile, R2 will remove this network from its routing table. Every time an interface goes up and down, packets are generated and the routing table will change. All of this requires bandwidth, CPU cycles, and memory. No problem for our small network but when you have thousands of networks and dozens of routers then it’s a different story.
With Route Summarization
Let’s see how route summarization works. I’ll configure R1 to advertise a summary towards R2:
R1(config)#interface GigabitEthernet 0/1
R1(config-if)#ip summary-address rip 172.16.0.0 255.255.0.0
Here’s what R1 advertises now:
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1 (192.168.12.1)
RIP: build update entries
172.16.0.0/16 via 0.0.0.0, metric 1, tag 0
And here’s what R2 receives:
RIP: received v2 update from 192.168.12.1 on GigabitEthernet0/1
172.16.0.0/16 via 0.0.0.0 in 1 hops
Only one network is advertised, our summary route. Less information, less bandwidth, less CPU cycles required and less memory. Here’s the routing table of R2:
R2#show ip route rip
R 172.16.0.0/16 [120/1] via 192.168.12.1, 00:00:10, GigabitEthernet0/1
Only one entry remains. R2 is still able to reach every network that our summary route covers. Let’s try this:
R2#ping 172.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/6 ms
This is looking good. Let me also show you one of the disadvantages of summarization. Here’s what happens when we ping an IP address that is covered by the summary route but which is not available:
R2#ping 172.16.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.4.4, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
The U means it’s unreachable. R2 has a matching route towards R1 so it sends these packets to R1. When R1 receives them, it drops them since it doesn’t have a matching entry and informs R2 about this.
Remember what happened when we shut one of the loopback interface? RIP would send a triggered update. Let’s try that again:
R1(config)#interface loopback 0
R1(config-if)#shutdown
Nothing will happen now! As long as there is one interface up with an IP address that falls within the summary route then the summary will be advertised. This makes our network far more stable.
Let me show you what happens when I shut the remaining loopbacks:
R1(config)#interface loopback 1
R1(config-if)#shutdown
R1(config)#interface loopback 2
R1(config-if)#shutdown
R1(config)#interface loopback 3
R1(config-if)#shutdown
Once I shut the last loopback, something happens:
R1#
RIP: sending v2 flash update to 224.0.0.9 via GigabitEthernet0/1 (192.168.12.1)
RIP: build flash update entries
172.16.0.0/16 via 0.0.0.0, metric 16, tag 0
Once the final loopback interface is gone, R1 sends the triggered update to inform R2 that the summary route is gone. Here’s R2:
R2#
RIP: received v2 update from 192.168.12.1 on GigabitEthernet0/1
172.16.0.0/16 via 0.0.0.0 in 16 hops (inaccessible)
There is one more disadvantage to summarization but to demonstrate this, I will have to add another router. Let’s add R3:
We use the same topology but R1 and R2 are now also connected to R3. Let’s make sure our loopback interfaces are up again:
R1(config)#interface range loopback 0 - 3
R1(config-if-range)#no shutdown
Let’s configure R1 so that it sends RIP packets to R3:
R1(config)#router rip
R1(config-router)#network 192.168.13.0
R1(config)#access-list 1 deny any
R1(config)#router rip
R1(config-router)distribute-list 1 in GigabitEthernet 0/2
Let’s configure R2:
R2(config-if)#router rip
R2(config-router)#network 192.168.23.0
And R3:
R3(config-if)#router rip
R3(config-R3)#version 2
R3(config-R3)#no auto-summary
R3(config-R3)#network 192.168.13.0
R3(config-R3)#network 192.168.23.0
Now let’s take a look at the routing tables:
R3#show ip route rip
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
R 172.16.0.0/16 [120/2] via 192.168.23.2, 00:00:22, GigabitEthernet0/2
R 172.16.0.0/24 [120/1] via 192.168.13.1, 00:00:24, GigabitEthernet0/1
R 172.16.1.0/24 [120/1] via 192.168.13.1, 00:00:24, GigabitEthernet0/1
R 172.16.2.0/24 [120/1] via 192.168.13.1, 00:00:24, GigabitEthernet0/1
R 172.16.3.0/24 [120/1] via 192.168.13.1, 00:00:24, GigabitEthernet0/1
R 192.168.12.0/24 [120/1] via 192.168.23.2, 00:00:22, GigabitEthernet0/2
[120/1] via 192.168.13.1, 00:00:24, GigabitEthernet0/1
Above you can see that R3 learns the summary route from R2, all other networks are learned from R1. Let’s check R2:
R2#show ip route rip
172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
R 172.16.0.0/16 [120/1] via 192.168.12.1, 00:00:08, GigabitEthernet0/1
R 172.16.0.0/24 [120/2] via 192.168.23.3, 00:00:10, GigabitEthernet0/2
R 172.16.1.0/24 [120/2] via 192.168.23.3, 00:00:10, GigabitEthernet0/2
R 172.16.2.0/24 [120/2] via 192.168.23.3, 00:00:10, GigabitEthernet0/2
R 172.16.3.0/24 [120/2] via 192.168.23.3, 00:00:10, GigabitEthernet0/2
R 192.168.13.0/24 [120/1] via 192.168.23.3, 00:00:10, GigabitEthernet0/2
[120/1] via 192.168.12.1, 00:00:08, GigabitEthernet0/1
Above you can see that we now have sub-optimal routing on R2. Since the router prefers the most specific path, it will use R3 to reach the four 172.16.x.0/24 networks and it’s not using the summary route from R1. We can verify this with a traceroute:
R2#traceroute 172.16.0.1 probe 1
Type escape sequence to abort.
Tracing the route to 172.16.0.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.23.3 5 msec
2 192.168.13.1 10 msec
There are a couple of different methods how you can solve this, depending on what routing protocol you select. This is something we will discuss in other lessons.
Configurations
Want to take a look for yourself? Here you will find the final configuration of each device.
R1
hostname R1
!
ip cef
!
interface Loopback0
ip address 172.16.0.1 255.255.255.0
!
interface Loopback1
ip address 172.16.1.1 255.255.255.0
!
interface Loopback2
ip address 172.16.2.1 255.255.255.0
!
interface Loopback3
ip address 172.16.3.1 255.255.255.0
!
interface GigabitEthernet0/1
ip address 192.168.12.1 255.255.255.0
ip summary-address rip 172.16.0.0 255.255.0.0
!
interface GigabitEthernet0/2
ip address 192.168.13.1 255.255.255.0
!
router rip
network 172.16.0.0
network 192.168.12.0
network 192.168.13.0
distribute-list 1 in GigabitEthernet0/2
no auto-summary
!
access-list 1 deny any
!
end
R2
hostname R2
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.12.2 255.255.255.0
!
interface GigabitEthernet0/2
ip address 192.168.23.2 255.255.255.0
!
router rip
network 192.168.12.0
network 192.168.23.0
no auto-summary
!
end
R3
hostname R3
!
ip cef
!
interface GigabitEthernet0/1
ip address 192.168.13.3 255.255.255.0
!
interface GigabitEthernet0/2
ip address 192.168.23.3 255.255.255.0
!
router rip
network 192.168.13.0
network 192.168.23.0
no auto-summary
!
end
Conclusion
You have now learned what route summarization is about and it’s advantages and disadvantages:
- Summarization means we advertise one summary route that represents multiple networks.
- Also known as route aggregation or supernetting.
- Saves CPU cycles, bandwidth and memory.
- Reduces the size of the routing table.
- Prevents routing table instability.
- Has two possible disadvantages:
- Forwarding traffic to non-existing networks.
- Sub-optimal routing.
Hi,
I think there is a mistake in the second line in
It should be “network 192.168.12.0” instead right ?
Hi Rene
I was thinking in order to fix this sub-optimal routing problem of Router R2, why not use the same summarization for the Gi0/2 on R1?
Please let me know if this would be a solution to this problem.
Thanks
Palani
Palani,
Your solution would work. What you propose doing would be essentially to suppress all specific /24 routes, and only advertise the /16 summary both to R3 and R2. In this case, since the prefix lengths are the same, R2 would fall back using the lowest metric to get to the summary, which for RIP would simply be hop count. R2 would choose the direct connection to R1.
Houari,
You are correct. I will request that this get corrected. Thanks for point this out.
Hii Rene,
1st query:
no auto-summary
command is issued to disable summary.and to enable summary can we use
R1(config-router)#auto-summary
command instead of usingR1(config-if)#ip summary-address rip 172.16.0.0 255.255.0.0
2nd Query:
In above RIP update wh
... Continue reading in our forum