JunOS | Aggregate Routes

There are two ays in which we could provide routing information to a router – using static, or dynamic routing. Either way, we should always try to keep the routing table small and optimal.

One way of optimising the routing tables is through the use of route aggregates.. JunOS defines two types of aggregates:
  1. Aggregate routes
  2. Generate routes
This post will highlight what aggregate routes are and how to configure them; I will leave Generate routes for another post.

An aggregate route has the following characteristics:

  • Routes summaries with the next hop set to reject by default; it can be set to discard
  • Activate when at least one contributing route exist in the routing table; however …
  • … an aggregate can be made persistent regardless of the existence of contributing routes, using the passive keyword
  • The contributing routes can be directly attached routes – ie. a clear next hop is not required
  • A route can only contribute to a single aggregate; as a result …
  • … aggregates can recursively activate other aggregates
  • Cannot be configured for Multicast routing tables – either IPv4 (inet.1) or IPv6 (inet6.1)

An aggregate route will have its next-hop set as discard by default (or reject – if configured). This means that when a route lookup is performed and the destination address is not successfully matched to any of the contributing routes, the only possible match would be the aggregate – which means the packet will get discarded (or rejected).


In the topology below, solid line arrows indicate routes configured on the device; dotted lines indicate flow of prefixes as dictated by the configured routing policy.

R1 has two directly connected networks configured as multiple IP addresses to Lo0.0 interface; these networks are and It has a static default route configured towards R2.

R2 is using static routes towards R1 so it can reach the locally attached networks on R1. R2 is running OSPF and has R3 as it’s directly connected neighbour; it is also running iBGP and peering with R3 as well. Default routing policies are used, unless otherwise configured. Lastly, R2 is configured in AS64501.

R3 is running OSPF and has R2 as it’s directly connected neighbour; it is also running iBGP and peering with R2. R3 is configured in AS64501. Lastly, it’s peering with ISP router via eBGP. Default routing policies are used, unless otherwise configured.

ISP router is advertising a default route to R3 via eBGP; it will also receive aggregate routes from R3


I will start by configuring the aggregate – this will include the two subnets and

set policy-options policy-statement aggregate_routes from protocol aggregate
set policy-options policy-statement aggregate_routes then accept
set routing-options router-id
set routing-options aggregate route

If we now check the routes being advertised to the ISP router via eBGP, from R3:

Let’s look at the routes received by the ISP router:

We can also see below how much more information we can get by using the detail switch of the show route command; notice how information about the contributing routes is also included:


If we look at the routing table on ISP router, we see that the aggregate from R3 as well as the contributing routes. Now that we have the aggregate being successfully advertised out, we don’t actually need to advertise the contributing routes anymore.

In order to suppress the advertisement of the contributing routes, we define an explicit BGP routing policy as below:

  1. We define a set of prefixes to match the contributing routes
  2. Define the actual route policy to reject the routes
  3. We apply the routing policy to the BGP neighbour

set policy-options prefix-list pl_10.200_24
set policy-options prefix-list pl_10.200_24

set policy-options policy-statement member_aggregate from prefix-list pl_10.200_24
set policy-options policy-statement member_aggregate then reject

set protocols bgp group eBGP_peers-AS64502 export member_aggregate

Above, we can see that the member routes and are now gone.


Aggregates get automatically activated providing the member routes are active in the routing table. It is however possible to change this behaviour so that the aggregate is persistent, regardless of the status of the member routes. This is achieved by using the passive keyword:

set routing-options aggregate route passive

We can now see above that even though the member routes are not in the routing table, the aggregate persists and it will therefore get advertised to router ISP.


show route <aggRoute> [detail | extensive]

show interface route protocol aggregate

There are quite a few other options applicable to both aggregate routes; but I will leave this out of the scope for this post.


Thank you,

Rafael A. Couto Cabral • LinkedIn Profile
Cisco​ | F5 | VMware Certified • PRINCE2 Practitioner

Originally posted 2021-11-28 00:32:41.

Related Post

Comments are closed.