In 2016, the big fashion was skinny jeans. In 2017 it was fidget spinners. And of course, in 2018 there’s only one trend on everyone’s lips: route summarisation.

Yes Sir/Madam, summarising prefixes is the craze that’s sweeping the world. Beyoncé’s doing it. All the kids want in on it. Even the Queen is said to enjoy nothing more on a Sunday evening than sitting in front of the TV with a pen and paper, and working out the best way to reduce the size of her routing table. Just because you’re rich doesn’t mean you can’t aim for an efficient use of your router’s memory, after all.

Of course, everything I’ve said so far is a lie. Let me make it up to you with some truth: in Junos there’s three ways to summarise routes. Want to know what they are? Well gosh damn, you’ve come to the right place!



Summary routes take one or more network prefixes, and combine them into one bigger prefix.

For example,,, and can be summarised as Advertising the one summarised prefix to your peers is far more efficient than advertising the four more specific routes. It keeps the routing table smaller, and it also means that your peers don’t need to worry about tiny flaps in your network. The interface hosting could go down, but the routers further down the way wouldn’t need to worry about that: it doesn’t change the fact that the entire /22 still exists in the same place.

Think of route summarisation as a bit like doing a nice gesture to the routers in your network. The sort of nice gesture that, for example, you might do to your grandfather, or to a dog that saved your life in March 1987.



There’s a three ways you can create summary routes in Junos

The first is simply to make a normal static route for the entire summary, but with a next hop of “discard”.

Now, if this is your first time learning about summary routes, you might be wondering: “Wait a second – why would I want to discard the traffic?” It seems counter-intuitive at first, doesn’t it? But remember: it’s only this summary route that has a next-hop of discard. The more specific prefixes will all have their own individual next-hops. And remember, a router always believe the most specific prefix in its routing table.

In other words, the traffic will only drop if there isn’t a more specific prefix in our routing table. Which is exactly what we want to happen! In our scenario above, if were to disappear, then we would indeed want that traffic to drop.

Let’s pretend we had a load of networks in the range. Here’s how you’d summarise it:

root# set routing-options static route discard

root> show route

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both *[Static/5] 00:00:05

Once we’ve made this summary static route, we could then create a routing policy to redistribute it into any protocol we like.

The problem with using static routes to summarise is that the summary stays in your routing table permanently. In the example I configured above, I don’t actually have any sub-networks on my device in the range. And yet, the summary route is in my routing table. This behaviour may or may not be what you want, but generally speaking you’ll want the summary to disappear if all the sub-networks also go down. And to achieve that, Junos gives us two other options. One of them is called aggregate routes, and the other is called generate routes. Let’s take a look at both of them.



Aggregate routes and generate routes are very similar in a lot of ways:

  • They both create summary routes in the routing table
  • They both have a route preference of 130, as opposed to 5 for the static route we just made (route preference is the Junos name for what some vendors call administrative distance)
  • Perhaps most importantly, they both only appear in the routing table if there’s at least one active, more specific subnet of the summary in the routing table – what Junos calls a “contributing” route
  • They both like long romantic walks on the beach (I expect)

There’s two big differences though.

The first is their next-hop behaviour. With an aggregate route, you can only have a next-hop of discard or reject. Both of these drop the traffic, but if you choose reject then Junos will also send an ICMP Unreachable message in reply. If you don’t specify which one you want to use, the traffic is rejected by default.

Generate routes, on the other hand, do indeed let you have a next-hop IP address. The summary route’s next-hop is taken from the “primary” contributing route’s next-hop. Which route is chosen as the primary, you ask? Here’s the process:

  • Choose the route with the lowest route preference (aka administrative distance)
  • If there’s more than one route with the same preference, use the lowest IP address number as a tie breaker

Only routes that have a working, valid next-hop can contribute to a generate route. That’s important to remember. It means that the presence of a directly-attached LAN will NOT contribute to a generated route, because there’s no clear next-hop.

Also, here’s a fun fact: generate routes also let you choose a next-hop of discard – but not reject. Why? I’ve no idea. My guess – and I stress the word guess – is that you’d choose generate when the presence of a next-hop is important, and you’d choose aggregate when you want to include directly-connected interfaces. Then again, when I was six I thought that televisions were full of tiny men and women putting on miniature plays all day, so don’t listen to my theories.

The other difference is what exactly counts as a contributing route. In an aggregate route, absolutely any prefix in the routing table counts as a contributing route. By contrast, generate routes will only accept a contributor if it has a next-hop to somewhere else. In other words, directly connected interfaces don’t count as contributors to generate routes.

This is actually quite handy. Imagine that you have a CPE with a single WAN link out, and imagine that you want to define a default route with a next-hop of a BGP peer at the other end of the WAN link. However, you only want the default route to go live if you’re learning prefixes by BGP. This is a great use case for a generate route. If you’re learning prefixes by BGP, the generate default will be live. If BGP goes down, the only prefixes in your router’s routing table will be ones from directly connected interfaces, which don’t count. Bye bye default route!



Take a look at my sweet topology. Let’s pretend I’ve got a big network of routers, with eight prefixes that are ripe for summarisation. Notice that this time I do indeed have lots of prefixes in the range.

CONFESSION: In reality I haven’t got a big network of routers at all: I just used Google™ to find a picture of a cloud, and then I put some numbers on top of it. This is fine for my demonstration, but if you’re an actual internet provider then please bear in mind that this won’t work in the real world. You’ll need to buy actual routers, not just draw a picture of a cloud and put it up in your data centre. Even if your frame the picture, it still won’t work. Your customers will be very angry with you if you try to do this, and they will sue you for a lot of money.

Anyway, the point is that there’s eight small networks in my cloud, which I want to summarise on Junos_R1. I then want to advertise this summary to my peers.

For our lab, let’s just add two of these prefixes into R1’s routing table, one from each range that we want to summarise. This will demonstrate that we don’t need every single prefix in R1’s routing table for the summary to go live, and that we actually only need the one “contributing” route:

set routing-options static route next-hop
set routing-options static route next-hop

Now we’ve added the smaller networks, let’s add our summary route. We’ll make one an aggregate, and one a generate. Here’s the syntax for each:

set routing-options aggregate route
set routing-options generate route



Use the command show route protocol aggregate to see both your aggregate AND your generate routes:

root> show route protocol aggregate

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
 + = Active Route, - = Last Active, * = Both *[Aggregate/130] 00:02:30
                   Reject *[Aggregate/130] 00:02:30
                   > to via ge-0/0/1.0

Notice that there isn’t a “show route protocol generate” command. Why? Because Juniper are smarter than us. Don’t question their superior reasoning. We all owe a gratitude to Barry Juniper (CEO of Juniper) for his continued quest to make things easy and simple to understand.

If you want to see whether a route is an aggregate or a generate route, you need to use the command show route protocol aggregate detail. Notice that the network has a Next Hop of, plus the “Generate” flag is set:

root> show route protocol aggregate detail

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
[ output trimmed for brevity ] (1 entry, 1 announced)
 *Aggregate Preference: 130
 Next hop type: Router, Next hop index: 569
 Address: 0x934c208
 Next-hop reference count: 7
 Next hop: via ge-0/0/1.0, selected
 Age: 6:27
 Task: Aggregate
 Announcement bits (1): 0-KRT
 AS path: I
 Flags: Generate Depth: 0 Active
 Contributing Routes (1): proto Static


Now our summary routes are in the routing table, we can make a policy for it, and advertise it to our peers. Here’s the syntax. Try it at home!

set policy-options policy-statement SUMMARY-POLICY term MY-SWEET-SUMMARY from protocol aggregate
set policy-options policy-statement SUMMARY-POLICY term MY-SWEET-SUMMARY then accept
set protocols bgp export SUMMARY-POLICY



Do you summarise routes in your network? Have you ever come across any problems? What was your solution? As always, I’d love to hear your stories in the comments, so please leave a note saying hi! Think of it like friendship. Though let me be absolutely clear: my real-world friendship costs two million US dollars a year.

If you’re on Mastodon, follow me to find out when I make new posts. (2024 edit: I’m also on BlueSky nowadays too. I was once on Twitter, but I’ve given up on it, on account of… well, I don’t need to finish that sentence, do I.)

And if you find my blog useful or entertaining, I’d love you to share it with your friends and co-workers, whether via a Twitter/Facebook/LinkedIn post, or just emailing it to them directly. Spread the world, and I’ll be inspired to write even more posts.

And if you fancy some more learning, take a look through my other posts. I’ve got plenty of cool new networking knowledge for you on this website, especially covering Juniper tech and service provider goodness.

It’s all free for you, although I’ll never say no to a donation. This website is 100% a non-profit endeavour, in fact it costs me money to run. I don’t mind that one bit, but it would be cool if I could break even on the web hosting, and the licenses I buy to bring you this sweet sweet content.


  • July 3, 2018 at 2:56 pm

    Nice, light touch…gets the info across but keeps my mind engaged with a bit silliness. Well done!

  • July 22, 2019 at 3:33 pm

    That’s awesome Chris… Thanks mate 🙂

  • December 25, 2019 at 11:44 pm

    Hi Chris,

    I have a question and hopefully, you can help me with it.

    Have you ever tried yo import access-internal routes into a specif rib-group?


  • March 16, 2020 at 6:38 pm

    Nice one Chris. I’ve never noticed the Generate flag in the show command before. Duh 🙂

  • July 22, 2020 at 6:30 pm

    Good post 🙂

    MY-SWEET-SUMMARY made me lol.


    Chris…. I accidentally sent you $3million, can you send me back the $1million?

    • July 22, 2020 at 11:17 pm

      No, but it does mean that you get to be my friend for a year and a half. Wow, what a great result!

  • July 29, 2020 at 7:02 am

    Heyy…You explain things in fun way.. I like it … before reading your blogs I thought networking is boring but you changed my perception … I hope you will publish whole book on networking some day with same writing style .. people will like ittt 🙂 🙂

    • August 1, 2020 at 4:01 pm

      Wow, high praise indeed Vinayak! Thank you very much!

  • October 8, 2020 at 12:08 am

    cracking explanation, thanks Chris!

    • October 9, 2020 at 7:14 am

      A cracking compliment! Cheers Mike!

  • October 10, 2021 at 10:26 pm

    You generate so much awesome humour along the way, with a very valid next hop , actually pointing to valuable knowledge. Gratitude to Barry and you !!!

    • October 11, 2021 at 12:29 pm

      Haha this is a brilliant comment! Thank you very much 🙂

  • July 14, 2023 at 4:31 am

    Thank you, I have struggled understanding the purpose of these two summary routes and how to spot and well differentiate them.. I don’t use them in our small mostly static routes network and needed this blog!


Leave a Reply

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