How to Configure an Aggregate Route Using Junos - dummies

How to Configure an Aggregate Route Using Junos

By Walter J. Goralski, Cathy Gadecki, Michael Bushong

As the number of devices connected to the Internet grows so, too, does the number of IP addresses assigned to those devices. And the more IP addresses, the more routes your router must maintain.

Even worse, as the number of routes increases, so does the time it takes to look up next-hop values. Transit time for traffic is dependent, at least in part, on the number of routes that are in each router’s routing table. For example, imagine a topology of interconnected networks.

An example of route aggregation.
An example of route aggregation.

Notice the depiction of three separate networks. Each network has been allocated a /16 prefix. A /16 prefix equates to 216 different addresses (216 = 65,535). So, if the entire Internet were to include only these three networks, each device would require 3 times 216 routes in its routing table, a large amount of stored data, not to mention the huge amount of time it would take to look up next hops.

You might think that every device in AS 3 needs a route to every device on AS 17. Everything has to go through the one border router anyway. It is sufficient to provide a route only to the border router for AS 3, which sends the traffic to AS 17, and the border router in AS 17 knows how to route within its own domain.

In fact, if the gateway router for AS 3 advertises only a summary of all the routes that fall within its domain, the number of routes it needs to advertise could be reduced from 216 to 1. As that route is propagated through the rest of the Internet, each device that wants to send traffic to a device in AS 3 needs to know only how to get to the border or gateway router.

This type of route summarization is called route aggregation. And if everyone plays nicely, the overall size of routing tables can remain relatively small, even when the total number of devices is quite large.

Aggregate routes must first be configured, and then they must be advertised. Examine this aggregate route.

An aggregate route to be advertised.
An aggregate route to be advertised.

To configure this aggregate route, simply identify it as an aggregate within the routing-options hierarchy:

[edit routing-options]
aggregate {;

Now all you have to do is advertise this route to your neighbor. Route advertisements are controlled through routing policy, of course. You’re peering with your neighbor through a BGP connection, and because it’s an advertisement, you want an export policy:

[edit policy-options]
policy-statement advertise-aggregate {
  term find-aggregate {
   from protocol aggregate;
   then accept;
[edit protocols’]
bgp {
  export advertise-aggregates;

This policy matches and accepts all aggregate routes. The policy is applied as an export policy, which means that BGP will send these aggregate routes to all BGP peers.

Here’s another way to look at it. Suppose that you had to route packages to each of the fifty states in the United States. There are ten of you all together. You have to tell the others what states you can reach. And you realize that all of your states begin with the letter M: Minnesota, Michigan, and so on.

In fact, you have all of those states, and none starting with any other letters. If it takes five minutes to write to each other “router,” you could send “I know how to reach Michigan. Send anything for Michigan over here!” and “I know how to reach Massachusetts. Send anything for Massachusetts over here!” and so on.

Or you could just create a single aggregate route and say “Anything with an M, send it here!” That’s the power of an aggregate.