Aggregate vs Generated Routes
January 1, 2026

In this post, we’ll look at how aggregated and generated routes work and under what conditions would you use them. Aggregated routes simplify your routing table by summarising networks, while generated routes can automatically create a route of last resort to keep traffic moving when no specific path exists

Definitions

Contributing Route

An active route in the forwarding table that contributes to the larger summary route defined by the aggregate or generated route command.

Introduction

Both aggregate and generated routes are methods of route summarisation with forwarding behaviour being the difference between the two. Understanding their purpose is simple once analysing the resulting behaviour. Both require a contributing route to be installed in the routing table for either to become active.

With aggregate routes, if traffic is destined to a network that is not a contributing route then that traffic will be dropped. The aggregate route is installed in the forwarding table with the next-hop of either a discard or reject statement. If traffic is destined to an active contributing route then traffic will be forwarded to the next-hop address defined by that route.

With a generated route, if traffic is destined to a network other than an active contributing route, a forwarding table lookup is made based on the preferred active contributor. Generated routes are often considered “routes of last resort”.

First let’s take a look at our environment below. We have a single upstream connection to our ISP from our border router and we’re exchanging routes via eBGP. Our border router then has a static route to our downstream firewall in order to activate the contributing routes.

vsrx-internal

set interfaces ge-0/0/2 unit 0 family inet address 172.16.0.8/31

set security zones security-zone untrust interfaces ge-0/0/2.0

vmx-border_router_1

set interfaces ge-0/0/2 unit 0 family inet address 172.16.0.9/31
set interfaces ge-0/0/5 unit 0 family inet address 203.0.113.11/31

set policy-options policy-statement export-routes-to-isp term t1 from protocol aggregate
set policy-options policy-statement export-routes-to-isp term t1 from route-filter 198.51.0.0/16 upto /24
set policy-options policy-statement export-routes-to-isp term t1 then accept
set policy-options policy-statement export-routes-to-isp term reject then reject

set routing-options autonomous-system 65215

set routing-options static route 198.51.100.0/27 next-hop 172.16.0.8

set routing-options aggregate route 198.51.100.0/24

set protocols bgp group isp-external type external
set protocols bgp group isp-external export export-routes-to-isp
set protocols bgp group isp-external peer-as 65512
set protocols bgp group isp-external neighbor 203.0.113.10

vmx-isp_1

set interfaces ge-0/0/5 unit 0 family inet address 203.0.113.10/31

set routing-options autonomous-system 65512

set protocols bgp group customer-external type external
set protocols bgp group customer-external peer-as 65215
set protocols bgp group customer-external neighbor 203.0.113.11

Aggregate Route

In our example we have configured an aggregate route of 198.51.100.0/24 but our only active and contributing route is 198.51.100.32/27. This /24 is going to be the public address space we’ll use across our organisation, but we’ve only got a few hosts we want to make available right now so we’re just advertising a /27.

The aggregate route has now been activated with the /27 route but only traffic to 198.51.100.32/27 will be reachable from the internet. Depending on the behaviour you configure as the next-hop (discard or reject), the packet will be dropped with or without an ICMP unreachable message.

The default is to reject which will send an ICMP unreachable message should there be no match on the contributing prefixes. The other option is discard which is the recommended option. This wont send an ICMP unreachable message which is preferable from a resource utilisation perspective but also to limit insight into your network.

Scenario: Traffic is destined to an address inside the 198.51.100.0/24 network but not matching the 198.51.100.32/27 route.

Outcome: Traffic is discarded or rejected depending on your configuration.

So how do both these route types help with summarisation? We expect our organisation to grow but right now there are only a few services we’re making publicly available hence the /27 we’ve reserved for those services.

We own the entire /16 network but we’re only going to advertise a /24 to the ISP to simplify the configuration, and avoid having to advertise anything else down the line should we begin to use more space.

Route summarisation also helps your neighbour in that the only route that gets installed in their routing table is the summary route, not the active contributing routes. If we advertised every /27 within that /24 range for example, that would be 8 routes rather than 1.

Now it is important to remember that you can only advertise aggregated routes to a neighbour if there is an active and contributing route in your forwarding table. In this scenario, if we wanted to advertise the entire /24 network without creating the static route (or having it by some other means of dynamic routing), then the route would not be active for us to export to our neighbour.

So not only does this method help summarise routes for neighbours, but as long as there is an active contributing route in the table where the aggregate route is generated, the neighbour will have reachability if we export the entire /24 range and we decide to add another network down the line such as 198.51.100.96/27.

Take a look at our route table below on the border router:

vmx-border_router_1

andrew-lab@vmx-border_router_1> show route table inet.0 

inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.0.8/31      *[Direct/0] 11:39:21
                    >  via ge-0/0/2.0
172.16.0.9/32      *[Local/0] 11:39:21
                       Local via ge-0/0/2.0
198.51.100.0/24    *[Aggregate/130] 00:05:52
                       Reject
198.51.100.64/27   *[Static/5] 00:17:14
                    >  to 172.16.0.8 via ge-0/0/2.0
203.0.113.10/31    *[Direct/0] 11:39:21
                    >  via ge-0/0/5.0
203.0.113.11/32    *[Local/0] 11:39:21
                       Local via ge-0/0/5.0

We have two entries in our route table above. One for the aggregate and the other for the static. You can see the reject statement under the first for the aggregate route.

Without our static route to 172.16.0.8, the aggregate route would not appear in the table so lets test that out. You can see the contributing route in the output below:

andrew-lab@vmx-border_router_1> show route protocol aggregate detail          

inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
198.51.100.0/24 (1 entry, 1 announced)
        *Aggregate Preference: 130
                Next hop type: Reject, Next hop index: 0
                Address: 0x8496c14
                Next-hop reference count: 2
                Kernel Table Id: 0
                State: <Active Int Ext>
                Local AS: 65215 
                Age: 3:49 
                Validation State: unverified 
                Task: Aggregate
                Announcement bits (2): 0-KRT 4-BGP_RT_Background 
                AS path: I  (LocalAgg)
                Flags:                  Depth: 0        Active
                AS path list (1):
                AS path: I Refcount: 1
                Contributing Routes (1):
                        198.51.100.64/27 proto Static
                Thread: junos-main

Let’s go ahead and deactivate that static route and see what happens to the output:

andrew-lab@vmx-border_router_1> configure 
Entering configuration mode

[edit]
andrew-lab@vmx-border_router_1# deactivate routing-options static route 198.51.100.64/27

[edit]
andrew-lab@vmx-border_router_1# commit and-quit    
commit complete
Exiting configuration mode
andrew-lab@vmx-border_router_1> show route table inet.0                            

inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.0.8/31      *[Direct/0] 01:01:06
                    >  via ge-0/0/2.0
172.16.0.9/32      *[Local/0] 01:01:06
                       Local via ge-0/0/2.0
203.0.113.10/31    *[Direct/0] 01:01:06
                    >  via ge-0/0/5.0
203.0.113.11/32    *[Local/0] 01:01:06
                       Local via ge-0/0/5.0
andrew-lab@vmx-border_router_1> show route protocol aggregate detail               

inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
andrew-lab@vmx-border_router_1> show route hidden 

inet.0: 8 destinations, 8 routes (7 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both

198.51.100.0/24       [Aggregate] 00:01:14
                       Reject

You can see all of the routes have been removed and our aggregate route is now hidden.

What happens if our services have expanded and we need to create another network? Let’s add a second route and see how the output changes.

andrew-lab@vmx-border_router_1> configure 
Entering configuration mode

[edit]
andrew-lab@vmx-border_router_1# set routing-options static route 198.51.100.96/27 next-hop 172.16.0.8

[edit]
andrew-lab@vmx-border_router_1# commit and-quit 
commit complete
Exiting configuration mode
andrew-lab@vmx-border_router_1> show route table inet.0                       

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.0.8/31      *[Direct/0] 11:42:39
                    >  via ge-0/0/2.0
172.16.0.9/32      *[Local/0] 11:42:39
                       Local via ge-0/0/2.0
198.51.100.0/24    *[Aggregate/130] 00:09:10
                       Reject
198.51.100.64/27   *[Static/5] 00:00:02
                    >  to 172.16.0.8 via ge-0/0/2.0
198.51.100.96/27   *[Static/5] 00:00:02
                    >  to 172.16.0.8 via ge-0/0/2.0
203.0.113.10/31    *[Direct/0] 11:42:39
                    >  via ge-0/0/5.0
203.0.113.11/32    *[Local/0] 11:42:39
                       Local via ge-0/0/5.0
andrew-lab@vmx-border_router_1> show route protocol aggregate detail          

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
198.51.100.0/24 (1 entry, 1 announced)
        *Aggregate Preference: 130
                Next hop type: Reject, Next hop index: 0
                Address: 0x8496c14
                Next-hop reference count: 2
                Kernel Table Id: 0
                State: <Active Int Ext>
                Local AS: 65215 
                Age: 9:42 
                Validation State: unverified 
                Task: Aggregate
                Announcement bits (2): 0-KRT 4-BGP_RT_Background 
                AS path: I  (LocalAgg)
                Flags:                  Depth: 0        Active
                AS path list (1):
                AS path: I Refcount: 3
                Contributing Routes (2):
                        198.51.100.64/27 proto Static
                        198.51.100.96/27 proto Static
                Thread: junos-main

Now we see our two contributing routes.

While we’re making changes, let’s change the aggregate route to discard.

andrew-lab@vmx-border_router_1> configure                                                
Entering configuration mode

[edit]
andrew-lab@vmx-border_router_1# set routing-options aggregate route 198.51.100.0/24 discard
andrew-lab@vmx-border_router_1> show route table inet.0                       

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.0.8/31      *[Direct/0] 11:43:57
                    >  via ge-0/0/2.0
172.16.0.9/32      *[Local/0] 11:43:57
                       Local via ge-0/0/2.0
198.51.100.0/24    *[Aggregate/130] 00:00:05
                       Discard
198.51.100.64/27   *[Static/5] 00:01:20
                    >  to 172.16.0.8 via ge-0/0/2.0
198.51.100.96/27   *[Static/5] 00:01:20
                    >  to 172.16.0.8 via ge-0/0/2.0
203.0.113.10/31    *[Direct/0] 11:43:57
                    >  via ge-0/0/5.0
203.0.113.11/32    *[Local/0] 11:43:57
                       Local via ge-0/0/5.0

Our table entry now shows discard instead of reject.

Now this is output from our network environment, but what does it look like from the ISP side?

vmx-isp_1

andrew-lab@vmx-isp_1> show route table inet.0    

inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

198.51.100.0/24    *[BGP/170] 00:11:38, localpref 100
                      AS path: 65215 I, validation-state: unverified
                    >  to 203.0.113.11 via ge-0/0/5.0
203.0.113.10/31    *[Direct/0] 11:45:07
                    >  via ge-0/0/5.0
203.0.113.10/32    *[Local/0] 11:45:07
                       Local via ge-0/0/5.0

Despite us having two static routes and an aggregate route configured, the ISP only ever sees our /24 route which is exactly what we intended.

Let’s talk about generated routes next, and remember the table output above because the main difference between the two is in the behaviour there.

Generated Route

Now that we understand the behaviour when configuring an aggregated route, what does it look like when we configure a generated route?

Unlike aggregate routes were the traffic is dropped if there is no specific match on the contributing route, generated routes have the ability to forward traffic.

Let’s keep our contributing routes in place but change the configuration from aggregate to generate. We want to keep our contributing routes in place because we want to see the next-hop change. We only have the one connected device right now so let’s add a second edge connection and create a new static route and make some changes:

vsrx-internal_2

set interfaces ge-0/0/1 unit 0 family inet address 172.16.0.1/31

set security zones security-zone untrust interfaces ge-0/0/1.0

vmx-border_router_1

set interfaces ge-0/0/1 unit 0 family inet address 172.16.0.0/31

Since the major difference between the aggregate and generated routes is the next-hop decision, let’s make a few changes to our static routes and examine the behavior:

vmx-border_router_1

andrew-lab@vmx-border_router_1> configure 
Entering configuration mode

[edit]
andrew-lab@vmx-border_router_1# delete routing-options aggregate route 198.51.100.0/24        

[edit]
andrew-lab@vmx-border_router_1# set routing-options generate route 198.51.100.0/24 

[edit]
andrew-lab@vmx-border_router_1# commit and-quit 
commit complete
Exiting configuration mode
andrew-lab@vmx-border_router_1> show route table inet.0    

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.0.0/31      *[Direct/0] 10:23:45
                    >  via ge-0/0/1.0
172.16.0.0/32      *[Local/0] 10:23:45
                       Local via ge-0/0/1.0
172.16.0.8/31      *[Direct/0] 11:47:15
                    >  via ge-0/0/2.0
172.16.0.9/32      *[Local/0] 11:47:15
                       Local via ge-0/0/2.0
198.51.100.0/24    *[Aggregate/130] 00:00:02
                    >  to 172.16.0.8 via ge-0/0/2.0
198.51.100.64/27   *[Static/5] 00:04:38
                    >  to 172.16.0.8 via ge-0/0/2.0
198.51.100.96/27   *[Static/5] 00:04:38
                    >  to 172.16.0.8 via ge-0/0/2.0
203.0.113.10/31    *[Direct/0] 11:47:15
                    >  via ge-0/0/5.0
203.0.113.11/32    *[Local/0] 11:47:15
                       Local via ge-0/0/5.0
andrew-lab@vmx-border_router_1> show route protocol aggregate detail          

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
198.51.100.0/24 (1 entry, 1 announced)
        *Aggregate Preference: 130
                Next hop type: Router, Next hop index: 577
                Address: 0x849f314
                Next-hop reference count: 9, Next-hop session id: 321
                Kernel Table Id: 0
                Next hop: 172.16.0.8 via ge-0/0/2.0, selected
                Session Id: 321
                State: <Active Int Ext>
                Local AS: 65215 
                Age: 1:39 
                Validation State: unverified 
                Task: Aggregate
                Announcement bits (2): 0-KRT 4-BGP_RT_Background 
                AS path: I 
                                Flags: Generate Depth: 0        Active
                Contributing Routes (2):
                        198.51.100.64/27 proto Static
                        198.51.100.96/27 proto Static
                Thread: junos-main

Let’s analyse the output.

This time we have a next-hop address of our downstream vsrx-internal device instead of a reject/discard.

So let’s revisit what we said in the first paragraph now, “…a forwarding table lookup is made to find a route based on the lowest numbered prefix.”

How can we test this?

Well we just installed a new downstream firewall and we’re about to create a new /26 route headed that way:

vmx-border_router_1

andrew-lab@vmx-border_router_1> configure 
Entering configuration mode

[edit]
andrew-lab@vmx-border_router_1# set routing-options static route 198.51.100.0/26 next-hop 172.16.0.1  

[edit]
andrew-lab@vmx-border_router_1# commit and-quit 
commit complete
Exiting configuration mode

Let’s take a look at the output again and highlight the changes:

andrew-lab@vmx-border_router_1> show route table inet.0                       

inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.0.0/31      *[Direct/0] 10:40:15
                    >  via ge-0/0/1.0
172.16.0.0/32      *[Local/0] 10:40:15
                       Local via ge-0/0/1.0
172.16.0.8/31      *[Direct/0] 12:03:45
                    >  via ge-0/0/2.0
172.16.0.9/32      *[Local/0] 12:03:45
                       Local via ge-0/0/2.0
198.51.100.0/24    *[Aggregate/130] 00:00:11
                    >  to 172.16.0.1 via ge-0/0/1.0
198.51.100.0/26    *[Static/5] 00:00:11
                    >  to 172.16.0.1 via ge-0/0/1.0
198.51.100.64/27   *[Static/5] 00:21:08
                    >  to 172.16.0.8 via ge-0/0/2.0
198.51.100.96/27   *[Static/5] 00:02:41
                    >  to 172.16.0.8 via ge-0/0/2.0
203.0.113.10/31    *[Direct/0] 12:03:45
                    >  via ge-0/0/5.0
203.0.113.11/32    *[Local/0] 12:03:45
                       Local via ge-0/0/5.0
andrew-lab@vmx-border_router_1> show route protocol aggregate detail 

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
198.51.100.0/24 (1 entry, 1 announced)
        *Aggregate Preference: 130
                Next hop type: Router, Next hop index: 585
                Address: 0x8498514
                Next-hop reference count: 5, Next-hop session id: 322
                Kernel Table Id: 0
                Next hop: 172.16.0.1 via ge-0/0/1.0, selected
                Session Id: 322
                State: <Active Int Ext>
                Local AS: 65215 
                Age: 1:07 
                Validation State: unverified 
                Task: Aggregate
                Announcement bits (2): 0-KRT 4-BGP_RT_Background 
                AS path: I 
                                Flags: Generate Depth: 0        Active
                Contributing Routes (3):
                        198.51.100.0/26 proto Static
                        198.51.100.64/27 proto Static
                        198.51.100.96/27 proto Static
                Thread: junos-main

The /26 route has now become an active contributing route but is also the route now used for the next-hop decision.

The more specific route would be one of the /27 routes but the lowest numbered prefix in our routing table is the /26 route we just installed and is why it is being used as the next-hop.

What if we have two static routes for the same destination but different valid next-hops?

andrew-lab@vmx-border_router_1> show route table inet.0                       

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

172.16.0.0/31      *[Direct/0] 1d 09:59:17
                    >  via ge-0/0/1.0
172.16.0.0/32      *[Local/0] 1d 09:59:17
                       Local via ge-0/0/1.0
172.16.0.8/31      *[Direct/0] 1d 11:22:47
                    >  via ge-0/0/2.0
172.16.0.9/32      *[Local/0] 1d 11:22:47
                       Local via ge-0/0/2.0
198.51.100.0/24    *[Aggregate/100] 22:57:28
                    >  to 172.16.0.1 via ge-0/0/1.0
                       to 172.16.0.8 via ge-0/0/2.0
198.51.100.0/26    *[Static/5] 00:00:34
                    >  to 172.16.0.1 via ge-0/0/1.0
                       to 172.16.0.8 via ge-0/0/2.0
198.51.100.64/27   *[Static/5] 23:40:10
                    >  to 172.16.0.8 via ge-0/0/2.0
198.51.100.96/27   *[Static/5] 23:21:43
                    >  to 172.16.0.8 via ge-0/0/2.0
203.0.113.10/31    *[Direct/0] 1d 11:22:47
                    >  via ge-0/0/5.0
203.0.113.11/32    *[Local/0] 1d 11:22:47
                       Local via ge-0/0/5.0
andrew-lab@vmx-border_router_1> show route protocol aggregate detail    

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
198.51.100.0/24 (1 entry, 1 announced)
        *Aggregate Preference: 100
                Next hop type: Router, Next hop index: 0
                Address: 0x89ebed4
                Next-hop reference count: 2, Next-hop session id: 0
                Kernel Table Id: 0
                Next hop: 172.16.0.1 via ge-0/0/1.0, selected
                Session Id: 0
                Next hop: 172.16.0.8 via ge-0/0/2.0
                Session Id: 0
                State: <Active Int Ext>
                Local AS: 65215 
                Age: 22:59:12 
                Validation State: unverified 
                Task: Aggregate
                Announcement bits (2): 0-KRT 4-BGP_RT_Background 
                AS path: I 
                                Flags: Generate Depth: 0        Active
                Contributing Routes (3):
                        198.51.100.0/26 proto Static
                        198.51.100.64/27 proto Static
                        198.51.100.96/27 proto Static
                Thread: junos-main

Two static routes with the same preference but different next hops and the router will choose the one with the lowest IP for the next-hop (.1 v .8).

Conclusion

Therein lies the major difference between the two route types. Both types are used for route summarisation but only one has the ability to forward traffic.

Documentation Links and KBs

https://www.juniper.net/documentation/us/en/software/junos/static-routing/topics/topic-map/config-route-aggregation.html

https://www.juniper.net/documentation/us/en/software/junos/static-routing/topics/concept/policy-generated-routes.html

byAndrew Johnstone
0
Comments
Join the Discussion and Share Your Opinion
Add a Comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Read Next