Introduction to Route Summarization

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:

R1 R2 Summarization Example

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:

R1 R2 R3 Summarization Example

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
The access-list on R1 is required to prevent R1 from installing any RIP routes from R3. Otherwise the summary route is advertised from R1 > R2 > R3 > R1, causing a routing loop.

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 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.

Forum Replies

  1. Hello Chandrasekhar

    The auto-summary command restores the default auto summarization behaviour of the routing protocol. RIP Version 1 always uses automatic summarization. If you are using RIP Version 2, you can turn off automatic summarization by specifying the no auto-summary command. Disable automatic summarization if you must perform routing between disconnected subnets. When automatic summarization is off, subnets are advertised. Note that this is

    ... Continue reading in our forum

  2. Hello… I have a question… and not sure why my routers are working that way… I have a summary address of 3 networks being advertised from R1 to R2… I used the command ip summary-address rip 172.16.0.0 255.255.224.0 to publish that route from R1 to a neighbor router R2…ok I desactivate this summary address with the command no ip summary-address rip 172.16.0.0 255.255.224.0 on router R1, and after a few seconds AGAIN I activate the command ip summary-address rip 172.16.0.0 255.255.224.0 on router R1, the problem is that now the summary address is gone forever… my

    ... Continue reading in our forum

  3. Hello Alvaro

    That’s interesting. Normally, when you reinstate the summary-address command, the summary address should appear in the RIP neighbor. Take a look at this text from a Cisco Document (link below).

    As long as there are child routes for a summary address, the address remains in the routing database. When the last child route is removed, the summary entry also is removed from the database. This method of handling database entries reduces the number of entries in the database because each child route is not listed in an entry, and the aggregate entry

    ... Continue reading in our forum

  4. Hello Alvaro

    Yes Alvaro, that makes sense. Poison reverse will cause R1 not to put the routes in the routing table. However, once you reinstate the summary route, after a certain amount of time, the poison reverse message will have timed out, this is how it should function. During the time that the networks are still “poisoned” can you use show ip protocols and show ip rip database and you can also continue to watch RIP debugs

    ... Continue reading in our forum

  5. Okay… thanks for your time. =)

14 more replies! Ask a question or join the discussion by visiting our Community Forum